Using Block Change Tracking to Improve Incremental Backup Performance

The block change tracking feature for incremental backups improves backup performance by recording changed blocks for each datafile.

About Block Change Tracking

If block change tracking is enabled on a primary or standby database, then RMAN uses a block change tracking to identify changed blocks for incremental backups. By reading this small bitmap file to determine which blocks changed, RMAN avoids having to scan every block in the datafile that it is backing up.

Block change tracking is disabled by default. Nevertheless, the benefits of avoiding full datafile scans during backup are considerable, especially if only a small percentage of data blocks are changed between backups. If your backup strategy involves incremental backups, then block change tracking is recommended. Block change tracking in no way changes the commands used to perform incremental backups. The change tracking files themselves generally require little maintenance after initial configuration.

Space Management in the Block Change Tracking File

The change tracking file maintains bitmaps that mark changes in the datafiles between backups. The database performs a bitmap switch before each backup. Oracle Database automatically manages space in the change tracking file to retain block change data that covers the 8 most recent backups. After the maximum of 8 bitmaps is reached, the most recent bitmap is overwritten by the bitmap that tracks the current changes.

The first level 0 incremental backup scans the entire datafile. Subsequent incremental backups use the block change tracking file to scan only the blocks that have been marked as changed since the last backup. An incremental backup can be optimized only when it is based on a parent backup that was made after the start of the oldest bitmap in the block change tracking file.

Consider the 8-bitmap limit when developing your incremental backup strategy. For example, if you make a level 0 database backup followed by 7 differential incremental backups, then the block change tracking file now includes 8 bitmaps. If you then make a cumulative level 1 incremental backup, then RMAN cannot optimize the backup because the bitmap corresponding to the parent level 0 backup is overwritten with the bitmap that tracks the current changes.

Location of the Block Change Tracking File

One block change tracking file is created for the whole database. By default, the change tracking file is created as an Oracle-managed file in the destination specified by the DB_CREATE_FILE_DEST initialization parameter. You can also specify the name of the block change tracking file by placing it in any location you choose. You can use a raw device (that is, a disk without a file system) as a block changing file, but be sure that the device is sufficiently large.

Note:

In an Oracle RAC environment, the change tracking file must be located on shared storage accessible from all nodes in the cluster.

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 the 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 size of the block change tracking file can increase and decrease as the database changes. The size is not related to the frequency of updates to the database.

Typically, the space required for block change tracking is approximately 1/30,000 the size of the data blocks to be tracked. The following factors that may cause the file to be larger than this estimate suggests:

• To avoid the overhead of allocating space as your database grows, 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.

Enabling and Disabling Block Change Tracking

You can enable block change tracking when the database is either open or mounted. This section assumes that you intend to create the block change tracking file as an Oracle-managed file in the database area, which is where the database maintains active database files such as datafiles, control files, and online redo log files. See "Overview of the Flash Recovery Area" to learn about the database area and flash recovery area.

To enable block change tracking:

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

Make sure that the DB_CREATE_FILE_DEST initialization parameter is set.

SHOW PARAMETER DB_CREATE_FILE_DEST

If the parameter is not set, and if the database is open, then you can set the parameter with the following form of the ALTER SYSTEM statement:

ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/disk1/bct/' SCOPE=BOTH SID='*';

Enable block change tracking.

Execute the following ALTER DATABASE statement:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

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

ALTER DATABASE 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.

Disabling Block Change Tracking

This section assumes that the block change tracking feature is currently enabled. When you disable block change tracking, the database removes the block change tracking file from the operating system.

To disable block change tracking:

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

Ensure that the target database is mounted or open.

Disable block change tracking.

Execute the following ALTER DATABASE statement:

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; Checking Whether Change Tracking is Enabled

You can query the V$BLOCK_CHANGE_TRACKING view to determine whether change tracking is enabled, and if it is, the filename of the block change tracking file.

To determine whether change tracking is enabled:

• Enter the following query in SQL*Plus (sample output included):

  COL STATUS FORMAT A8

           COL FILENAME FORMAT A60

           SELECT STATUS, FILENAMEFROM V$BLOCK_CHANGE_TRACKING;
STATUS       FILENAME
ENABLED      /disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg

Changing the Location of the Block Change Tracking File

To move the change tracking file, use the ALTER DATABASE RENAME FILE statement. 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.

To change the location of the change tracking file:

Start SQL*Plus and connect to a target database.

If necessary, determine the current name of the change tracking file:

SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING;

If possible, shut down the database. For example:

SQL> 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:

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;SQL> 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:

SQL> ALTER DATABASE OPEN;

我们可以用下面的语句查询是否有增量

alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

select file#, incremental_level, completion_time, datafile_blocks ,blocks_read,trunc((blocks_read / datafile_blocks) * 100,2) as "read%",used_change_tracking from v$backup_datafile;

在使用RMAN 增量备份的情况下，启动block change tracking，在做增量备份时会缩短RMAN 备份的时间， 因为不用扫描整个data file。 但是block tracking 也会带来其他的一些开销。 所以要根据实际情况决定是否启用block change tracking。

pxboracle@live.com
2014.04.22 09:41