Oracle backup

zlodey

Участник
Привет, в сети имеется несколько экземпляров виртуальных серверов Oracle 11g. Задача - снимать раз в неделю полный бэкап instance и остальные дни инкрементальный бэкап. В качестве бэкапного софта используется Symantec Backup Exec 2015 и agent for applications and databases. Все ПО абсолютно честное. Есть ли какие-либо тонкости при снятии бэкапа с оракловых баз данных? Почему то настроить бэкап не удается пишет что Oracle database - недоступно.
 
Хм. Есть только кусок из best practices:

Description
Best practices include tips and recommendations to help you use Backup Exec Agent for Oracle on Windows or Linux Servers (Oracle Agent) effectively. For more information about the Oracle Agent, see the Backup Exec Administrator's Guide.

The following best practices help you use the Oracle Agent effectively:

- Enable the Oracle archive log mode and the Oracle automatic archival of log files.
- Know the DBID and other important configuration details of the database.
- Know the names of the init<SID>.ora and the spfiles for the instances on the Oracle server.
- Do not store the RMAN Repository on the same server that holds the database that you want to back up.
- Back up your current control file when you run a Database Administrator (DBA) initiated job. If you have a backup of the current control file, then you do not have to search media to find a control file that is available for recovery.
- Test recovery scenarios often to get comfortable with the restore procedures. Oracle recovery can be complex and is often time-sensitive due to the nature of the data involved. Symantec recommends that you coordinate test plans and configuration activities with your Oracle DBA to be sure that restore procedures are confirmed.
- Use RMAN scripts to do the following:
Delete all archive log copies in a multiplexed archive log configuration.
Note: You can use Backup Exec to delete all non-multiplexed, single location archive logs.
- Run RMAN optimization.
The following best practices should be considered when you back up Oracle databases:
- Take a full backup whenever you make structural changes to a database.
- Do not delete archived log files unless you have two confirmed backups of each log.
- Create Oracle-specific media sets and backup jobs for the following reasons:

- RMAN can manage media retention and can communicate to the Backup Exec server that backup sets are expired. RMAN can successfully manage the media's retention period as long as unrelated backup sets are not present. Unrelated backup sets may have retention periods that are longer than the RMAN retention period.
- Media sets for Oracle backups should have a retention period that is greater than the CONTROL_FILE_RECORD_KEEP_TIME setting. By default, the CONTROL_FILE_RECORD_KEEP_TIME is 7 days. If the media sets for the Oracle backups have a greater retention period, backup sets are not overwritten and RMAN is not updated.
- When you configure multiple job streams in Oracle, additional resources such as file systems can cause more devices than expected to allocate drives.
- Load balance Oracle jobs between managed Backup Exec servers in a CASO environment. However, this scenario means that archived log file backups may reside on multiple managed Backup Exec servers, which makes restores complicated.
- Consider port re-assignments when you use RALUS in a Linux environment. Applications such as Webmin that uses port 10000 can interfere with RALUS operations.
- Enable the Oracle block change tracking for faster incremental backups.
- Enable Backup Exec compression when you configure general options for backup jobs.
- Ensure that you enter the fully qualified domain name of the Oracle server when you add it to list of servers on the Backup and Restore tab.
- Ensure that you add the fully qualified domain name of the Oracle server and the logon account name to the Backup Exec server's list of Oracle servers and authentication credentials.

The following best practices must be considered if you use the Oracle 12c database:

-Take a full backup of a container database (CDB) whenever there are any structural changes, such as addition of a new pluggable database (PDB).
-Include the root of the CDB in the backups to ensure that metadata of the CDB is always backed up.
-Run the database in the archive log mode to ensure that the database can be recovered to point in time.
-If the CDB is in no-archive log mode, then before backing up the PDBs, shut down the CDB. To avoid shutting down the CDB, you can either run the database in archive log mode or run a DBA-initiated backup of PDBs.
-Oracle recommends users to not only restore the root because it might cause metadata inconsistencies. Instead, you should recover the whole CDB.
-If the PDB point-in-time (PIT) restore fails, then consecutive jobs might also fail with the following error message:

ORA-19852: Error creating services for auxiliary instance.

This error occurs because the previous failed PIT restore attempts were not cleaned up properly. To solve this issue, you must clean the failed database PIT restore attempts. Perform the following steps to clean up the failed auxiliary service creation attempts:

Use the Database (DB) PIT recovery package to clean up the auxiliary instance in case of failed PIT jobs:

SQL> exec dbms_backup_restore.manageauxinstance ('DBPITR',1);

Also, run the last set of commands in the RMAN script to clear the RMAN configuration.
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' CLEAR;
CONFIGURE AUXILIARY CHANNEL DEVICE TYPE 'SBT_TAPE' CLEAR;
https://support.symantec.com/en_US/a...OWTO74434.html
Вот это тоже полезно будет:
 
Назад
Верх Низ