Another way to improve the performance of incremental backups is to enable block change tracking. For a traditional incremental backup, RMAN must inspect every block of the tablespace or datafile to be backed up to see if the block has changed since the last backup. For a very large database, the time it takes to scan the blocks in the database can easily exceed the time it takes to perform the actual backup.

By enabling block change tracking, RMAN knows which blocks have changed by using a change tracking file. Although there is some slight overhead in space usage and maintenance of the tracking file every time a block is changed, the tradeoff is well worth it if frequent incremental backups are performed on the database.

Block change tracking is disabled by default. If your backup strategy involves incremental backups, then block change tracking is recommended.

RMAN does not support backup and recovery of the change tracking file. The database resets the change tracking file when it determines that the change tracking file is invalid. If you restore and recover the whole database or a subset, then the database clears the block change tracking file and starts tracking changes again. After you make a level 0 incremental backup, the next incremental backup is able to use change tracking data.

Size of Block Change Tracking file

The size of the block change tracking file is proportional to the size of the database and the number of enabled threads of redo. The block change tracking file size starts at 10 MB. New space is allocated in 10 MB increments. Thus, for any database up to approximately 300 GB, the file size is no smaller than 10 MB, for up to approximately 600 GB the file size is no smaller than 20 MB, and so on.

For each datafile, a minimum of 320 KB of space is allocated in the block change tracking file, regardless of the size of the datafile. Thus, if you have a large number of relatively small datafiles, the change tracking file is larger than for databases with a smaller number of larger datafiles containing the same data.

Enable block change tracking file:

To enable block change tracking file database must be open or mounted. Following example enable block change tracking file to the location (DB_CREATE_FILE_DEST which specifies default location for oracle-managed datafile)

Start SQL*Plus and connect to a target database with administrator privileges.

ALTER DATABASE ENABLE
BLOCK CHANGE TRACKING;

Enable block change tracking file to specific location:

You can also create the change tracking file in a location you choose yourself by using the following form of SQL statement:

ALTERDATABASE ENABLE
BLOCK CHANGE TRACKING
USING FILE '/mydir/rman_change_track.f' REUSE;

The REUSE option tells Oracle Database to overwrite any existing block change tracking file with the specified name.

Disable block change tracking file:

When you disable block change tracking, the database removes the block change tracking file from the operating system.

Start SQL*Plus and connect to a target database with administrator privileges. Ensure that the target database is mounted or open.

SQL> ALTER DATABASE DISABLE
BLOCK CHANGE TRACKING;

Block change tracking file status

The dynamic performance view V$BLOCK_CHANGE_TRACKING contains the name and size of the block change tracking file as well as whether change tracking is enabled:

Start SQL*Plus and connect to a target database with administrator privileges.

COL STATUS FORMAT A8
COL FILENAME FORMAT A60
SELECT STATUS, FILENAME, BYTES
FROM V$BLOCK_CHANGE_TRACKING;
STATUS    FILENAME
-------- ------------------------------------------------------------
ENABLED /disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg

Change Location of Block Change Tracking File

The database must be mounted. The statement updates the control file to refer to the new location and preserves the contents of the change tracking file. If you cannot shut down the database, then you can disable and enable block change tracking. In this case, you lose the contents of the existing block change tracking file.

  • Start SQL*Plus and connect to a target database.
  • Determine the current name of the change tracking file:
SELECT FILENAME FROM 
V$BLOCK_CHANGE_TRACKING;
  • If possible, shut down the database. For example:
SHUTDOWN IMMEDIATE
  • If you shut down the database, then skip to the next step. If you choose not to shut down the database, then execute the following SQL statements and skip all remaining steps:
ALTER DATABASE DISABLE 
BLOCK CHANGE TRACKING;
ALTER DATABASE ENABLE 
BLOCK CHANGE TRACKING
USING FILE 'new_location';

In this case you lose the contents of the block change tracking file. Until the next time you complete a level 0 incremental backup, RMAN must scan the entire file.

  • Using host operating system commands, move the change tracking file to its new location.
  • Mount the database and move the change tracking file to a location that has more space. For example:
ALTER DATABASE RENAME FILE
'/disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg' TO
'/disk2/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg';

This statement changes the location of the change tracking file while preserving its contents.

  • Open the database:
ALTER DATABASE OPEN;
Go to top
JSN Boot template designed by JoomlaShine.com