Backing up a database is one of the usual DBA tasks and is a mandatory job on production systems. Recovery Manager (RMAN) has been supplied and recommended by Oracle, and provides effective, fast, and manageable methods to back up, restore, and recover an Oracle Database. Therefore, it is the most commonly used backup and recovery manager for Oracle Databases.
When used with Data Guard, RMAN offers extra safety and effectiveness to database administrators. It's possible to use a backup taken on the standby in order to restore and recover a primary database, and vice versa. Datafile, control file, and archived log file backups are interchangeable in a Data Guard environment. So we can prefer carrying the backup load on the primary database to a standby, or back up both the primary and standby for more data security. We can also use standby databases for the block change tracking (BCT) feature; it increases the incremental backup performance by identifying the changed data blocks since the last incremental backup.
We need to build an integrated environment to take advantage of using RMAN in a Data Guard configuration. Let's see the requirements and best practices for integrating these two Oracle database components.
The most important point of this integration is the fact that only physical standby databases can be used for interchangeable backups. If you recall, logical standby databases are not block copies of the primary database, so they may be in a different physical structure from it. So it's not possible to use a logical standby backup to restore and recover a primary database. The backup consideration of logical standby databases must be dealt with separately. However, a physical standby backup can be used to restore and recover the primary or any other physical standby databases in the Data Guard configuration.
An RMAN Catalog application is used to record the backup information of different databases in a centrally located system for easy access and use in case of database breakdowns. It's an option that is preferred in an environment with a large number of Oracle databases; however, RMAN Catalog has to be used in a Data Guard environment for successful integration. Otherwise, it will not be possible for the databases to be aware of backups taken from others in the same Data Guard configuration without a manual operation.
Tip
We should place the RMAN Catalog in a separate server from the primary and standby database servers, so that it will be possible to access the catalog that contains the necessary backup information in the case of any database server breakdown. We should also consider the high availability and disaster recovery requirements of the RMAN Catalog database.
In 11g, databases in the Data Guard configuration should have different DB_UNIQUE_NAME values. We're saying should because, if it's a simple configuration with no broker, fast-start failover, TAF, and so on, it's possible to run Data Guard with the same DB_UNIQUE_NAME value on the primary and standby databases. However, this is not a recommended configuration.
When performing a backup in a Data Guard environment, RMAN records the backup information by associating it with the DB_UNIQUE_NAME value of the database. So it's important to set different values for the primary database and for all the standby databases for a proper integration.
We should follow some general best practices when using RMAN for backing up and recovering Oracle databases. These best practices are also valid in a Data Guard configuration. Some of them are as follows:
- Enabling a fast recovery area for an effective disk backup strategy
- Keeping the flashback database on in order to return the database and objects to their state at a previous point in time without a full restore of the database
- Using
SPFILEand settingAUTOBACKUPon to automate backups ofSPFILEand the control file at the end of all RMAN backup operations - Enabling block change tracking for fast increment backups
- Configuring an appropriate parallelism setting for the better performance of RMAN operations
After learning the requirements and best practices, now let's see what we should accomplish to create an integrated environment.
Note
It is assumed that there is an RMAN Catalog database ready to use. For testing purposes, you can use your Data Guard test servers to create a catalog. Creating an RMAN catalog is not within the scope of this book, so you should follow related documentation to complete this job, which is quite easy.
We'll start with introducing the primary database to the RMAN Catalog application using the REGISTER command. Only the primary database has to be registered in the RMAN Catalog application. A physical standby database will be registered automatically when we connect it as a target to the RMAN Catalog application.
Run the following commands on the primary host to register the primary database in the RMAN Catalog application:
$ rman Recovery Manager: Release 11.2.0.1.0 - Production on Wed Oct 10 13:46:15 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. RMAN> CONNECT TARGET / connected to target database: ORCL (DBID=1319333016) RMAN> CONNECT CATALOG RMAN/RMAN@RMANCAT connected to recovery catalog database RMAN> REGISTER DATABASE; database registered in recovery catalog starting full resync of recovery catalog full resync complete
After registering the primary database in the catalog, we should now configure some RMAN settings. First, specify a retention policy to specify for how long a period of time it is guaranteed to do a point-in-time recovery. Backups older than the retention policy will be marked as OBSOLETE, which means that they are not needed.
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
If backups are to be run on the primary database, turn on automatic backup of the control file and turn on backup optimization; this will prevent the unnecessary backup of a datafile that has been unchanged since its last backup.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
We should set an archived log deletion policy for the primary database. If archived log backups will be taken from the primary database, we can set the policy to NONE in order to let the database manage the deletion regarding the FRA space or set a policy to mark the archived logs as OBSOLETE depending on the number of existing disk/tape backups.
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
We can also use the following command instead of the previous one:
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DEVICE TYPE DISK;
If archived log backups are not taken from the primary database, the retention policy will mark them as OBSOLETE as they are shipped/applied on the standby databases:
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
You can also use the following command:
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
We'll now specify net service names for the databases in the Data Guard configuration with the following commands:
RMAN> CONFIGURE DB_UNIQUE_NAME TURKEY_UN CONNECT IDENTIFIER 'TURKEY'; RMAN> CONFIGURE DB_UNIQUE_NAME INDIA_PS CONNECT IDENTIFIER 'INDIAPS';
Using these net service names, the RMAN target database will connect to other databases of the Data Guard when the RESYNC CATALOG FROM DB_UNIQUE_NAME command is executed. This command is used to make RMAN Catalog consistent with the specified database control file. It updates physical database structure (tablespace, datafile), archived log, and backup records in the catalog. It's good practice to use the RESYNC CATALOG FROM DB_UNIQUE_NAME ALL command in the scheduled RMAN script in a Data Guard environment.
Let's check those databases of Data Guard that are known to RMAN Catalog. We'll be able to see all the databases specified with the CONFIGURE DB_UNIQUE_NAME command:
RMAN> LIST DB_UNIQUE_NAME OF DATABASE; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 2 ORCL 1319333016 PRIMARY TURKEY_UN 2 ORCL 1319333016 STANDBY INDIA_PS
We should first decide whether we'll use a physical standby as the source for database backups. The best practice is to back up both the primary and the standby databases. If this is not preferred, the network between the primary and standby databases is determinant. It won't be feasible to run backups only on the standby, where it's connected to the primary database over a WAN network. This will dramatically affect the restore time on the primary database, which is not acceptable. If both databases are in the same LAN, we can consider running backups only on the standby database.
If backups are to be taken from the standby database, connect the RMAN Catalog application and the physical standby as targets to configure the settings for the standby database. We should turn on automatic backup for the control file and backup optimization.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
Then we should set the archived log deletion policy. We should use the similar strategy that is mentioned in the primary database RMAN settings. So if we want to back up the archived logs on the standby, we should set the deletion policy to NONE or set a policy to mark the archived logs as OBSOLETE depending on the number of existing disk/tape backups. If no archived log backup is running on the standby, use the APPLIED ON STANDBY policy for archived log deletion.
We can check the configuration for all the databases in the Data Guard configuration by connecting to any of the databases and the recovery catalog. Use the SHOW ALL command with the FOR DB_UNIQUE_NAME option to check the values of the RMAN parameters for the specified database:
RMAN> SHOW ALL FOR DB_UNIQUE_NAME TURKEY_UN; RMAN configuration parameters for database with db_unique_name TURKEY_UN are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE DB_UNIQUE_NAME 'TURKEY_UN' CONNECT IDENTIFIER 'TURKEY'; CONFIGURE DB_UNIQUE_NAME 'INDIA_PS' CONNECT IDENTIFIER 'INDIAPS'; CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle2/product/11.2.0/dbhome_1/dbs/snapcf_INDIAPS.f'; # default RMAN> SHOW ALL FOR DB_UNIQUE_NAME INDIA_PS; RMAN configuration parameters for database with db_unique_name INDIA_PS are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE DB_UNIQUE_NAME 'TURKEY_UN' CONNECT IDENTIFIER 'TURKEY'; CONFIGURE DB_UNIQUE_NAME 'INDIA_PS' CONNECT IDENTIFIER 'INDIAPS'; CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle2/product/11.2.0/dbhome_1/dbs/snapcf_INDIAPS.f'; # default
We've successfully completed the integration of the Data Guard environment with RMAN. At this stage, all the databases in the Data Guard administration will be aware of any backup taken with RMAN Catalog connection. If the backup is on tape and there is an accurate configuration between the tape library and all the database servers, any database in the Data Guard administration can use that backup for a restoration. If the backup is on the disk, it has to be on a shared filesystem across all databases of the Data Guard administration in order to be used by other databases. Otherwise, we need to transfer the backup files to other database servers and register them manually if needed.
Now let's perform a recovery scenario in which the primary datafile is lost and recovered using the backup of the standby database datafile that is then taken to the disk immediately.