- Let's simulate a case where a datafile is lost by renaming one of the datafiles. Shut down the database, rename the datafile with the
mvcommand, and start the database again. We'll see thecannot identify/lock data fileerror on startup.SQL> shutdown immediate $ mv /u01/app/oracle2/datafile/ORCL/users01.dbf /u01/app/oracle2/datafile/ORCL/users01.dbf.old SQL> startup ORACLE instance started. Total System Global Area 1603411968 bytes Fixed Size 2213776 bytes Variable Size 872417392 bytes Database Buffers 671088640 bytes Redo Buffers 57692160 bytes Database mounted. ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01110: data file 4: '/u01/app/oracle2/datafile/ORCL/users01.dbf'
- Now we'll run an RMAN datafile backup using the standby database as the source and locating the backup file in the primary database. Connect the standby database as the target, and the primary database as the auxiliary; then back up the datafile. It's not mandatory to connect RMAN Catalog because we'll register the backup file to the primary database's control file manually.
$ rman RMAN> connect TARGET sys/password@INDIAPS RMAN> connect AUXILIARY sys/password@TURKEY RMAN> backup as copy datafile 4 auxiliary format '/backup/users01_bckp.dbf'; Starting backup at 10-OCT-12 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=1239 device type=DISK channel ORA_DISK_1: starting datafile copy input datafile file number=00004 name=/u01/app/oracle2/datafile/INDIAPS/users01.dbf output file name=/backup/users01_bckp.dbf tag=TAG20121010T164250 RECID=10 STAMP=796322590 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25 Finished backup at 10-OCT-12
- We must register the backup file to the primary database control file with the
RMAN CATALOGcommand. On the primary database server, connect the database as the target and execute the following statements:$ rman RMAN> connect target / connected to target database: ORCL (DBID=1319333016) RMAN> catalog datafilecopy '/backup/users01_bckp.dbf'; using target database control file instead of recovery catalog cataloged datafile copy datafile copy file name=/backup/users01_bckp.dbf' RECID=4 STAMP=796322862
- Switch the datafile
4to the backup copy that we registered in the previous step:RMAN> switch datafile 4 to copy; datafile 4 switched to datafile copy "/backup/users01_bckp.dbf"
- Execute the
RECOVER DATABASEcommand on SQL*Plus and open the primary database:SQL> recover database; Media recovery complete. SQL> alter database open; Database altered.
We've gone through Data Guard and RMAN integration and then executed a primary database recovery example scenario in which the standby database backup was used. If the backup has been performed on the standby database to be taped periodically, we can also use these tape backups to restore files to the primary database.
Now simulate the opposite situation, that is, a datafile loss on the standby database. Rename a datafile on the standby database and then recover the database using a backup of the datafile taken from the primary database.
Block change tracking is a useful RMAN feature that is used to increase incremental backup performance. If it's enabled, changed blocks in each datafile will be recorded in a change-tracking file. When we perform an incremental RMAN backup, this file will be used to identify the changed blocks, so it will not be necessary for the RMAN incremental backup job to scan every block in the datafiles. This considerably improves the performance of the incremental backup jobs and some minimal performance overhead on the database during normal operations.
The ability to use standby databases for block change tracking is an 11g feature and requires an Oracle Active Data Guard license. This feature removes the performance overhead of BCT from primary databases. We use the following SQL statement on the standby database to enable BCT:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/backup/bct/block_change.log'; Database altered. SQL> SELECT FILENAME, STATUS FROM V$BLOCK_CHANGE_TRACKING; FILENAME STATUS ---------------------------- ---------- /backup/bct/block_change.log ENABLED
When enabled, the block change tracking file that is 10 MB in size is created and grows as needed. It won't be wrong to estimate its maximum size as a few gigabytes.
Besides the advantages provided by block change tracking for backup performance, there are several important bugs for enabling block change tracking on the standby database; this causes the backup jobs to hang and it causes incorrect backups and data loss. These bugs (for example, bugs 9869287, 9068088, 10094823, and so on) were fixed in the later releases, so it's important to check for relevant BCT bugs in the database version before enabling it on the physical standby.
Block change tracking can be disabled with the following statement:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;