How to Enable RMAN block change tracking for a physical standby database
Enabling Block Change Tracking on a Physical Standby Database
With the Oracle Active Data Guard option, you can enable block change tracking on a physical standby database. When you back up the physical standby database, RMAN uses the block change tracking file to quickly identify the blocks that have changed since the last incremental backup. RMAN reads only the changed blocks rather than the entire data file.
- Enable block change tracking on a physical standby database for fast incremental backups.
- Data file blocks that are affected by each database update are tracked in a block change tracking file.
- The block change tracking file is a binary file used by RMAN to record changed blocks to improve incremental backup performance.
Creating Fast Incremental Backups
The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of data files, tablespaces, or the entire database. During media recovery, RMAN examines the restored files to determine whether it can recover them from an incremental backup. RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than reapplying individual changes.
If you enable the block change tracking feature, Oracle Database tracks the physical location of all database changes in the change tracking file. RMAN uses this change-tracking data to determine which blocks to read during an incremental backup, creating much faster incremental backups by eliminating the need to read the entire data file The maintenance of incremental backups by eliminating the need to read the entire data file. The maintenance of this file is fully automatic and does not require your intervention. The size of the change tracking file is proportional to the following:
- Database size in bytes
- Number of enabled threads in a RAC environment
- Number of old backups maintained by the change tracking file
The minimum size for the change tracking file is 10 MB; new space is allocated in 10 MB The minimum size for the change tracking file is 10 MB; new space is allocated in 10 MB increments. By default, the Oracle Database server does not record block-change information.
Enabling Block Change Tracking
You enable block change tracking from the database home page. Click the Policy tab on the Backup Settings page. You do not need to set the change tracking file destination if the DB_CREATE_FILE_DEST initialization parameter is set, because the file is created as an Oracle Managed File (OMF) file in the DB_CREATE_FILE_DEST location. You can, however, specify the name of the change tracking file and place it in any location you choose.
FIGURE
You can also enable or disable block change tracking by using an ALTER DATABASE SQL command. If the change tracking file is stored in the database area with your database files, it is deleted when you disable change tracking.
ALTER DATABASE
{ENABLE|DISABLE} BLOCK CHANGE TRACKING
[USING FILE '...']
You can rename the change tracking file by using the ALTER DATABASE RENAME SQL command Your database must be in the command. Your database must be in the MOUNT state to rename the tracking file The state to rename the tracking file. The ALTER DATABASE RENAME FILE command updates the control file to refer to the new location. Use the following syntax to rename the change tracking file:
ALTER DATABASE RENAME FILE '...' TO '...';
Monitoring Block Change Tracking
The output of the V$BLOCK_CHANGE_TRACKING view shows where the change tracking file is located, the status of block change tracking (ENABLED/DISABLED), and the size (in bytes) of the file.
SQL> SELECT filename, status, bytes FROM v$block_change_tracking;
Querying the V$BACKUP_DATAFILE view shows the effectiveness of block change tracking in minimizing the incremental backup I/O (the PCT_READ_FOR_BACKUP column). A high value indicates that RMAN reads most blocks in the data file during an incremental backup. You can reduce this ratio by decreasing the time between incremental backups.
SQL> SELECT file#, avg(datafile_blocks),
2 avg(blocks_read),
3 avg(blocks_read/datafile_blocks)
4 * 100 AS PCT_READ_FOR_BACKUP,
5 avg(blocks)
5 FROM v$backup_datafile
6 WHERE used_change_tracking = 'YES'
7 AND incremental_level > 0
8 GROUP BY file#;
Sample Formatted Output from the V$BACKUP_DATAFILE Query
FILE# BLOCKS_IN_FILE BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP
----- -------------- ----------- ------------------- ----------------
1 56320 4480 7 462
2 3840 2688 70 2408
3 49920 16768 33 4457
4 640 64 10 1
5 19200 256 1 91