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 file 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 file requires no maintenance after initial configuration.
You can only enable block change tracking at a physical standby database if a license
for the Oracle Active Data Guard option is enabled.
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 oldest 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 place the change tracking file in any location you choose, by
specifying its name when enabling block change tracking. Oracle recommends against
using a raw device (that is, a disk without a file system) as a change tracking file.
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 resets 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 for a single instance is
approximately 1/30,000 the size of the data blocks to be tracked. For an Oracle RAC
environment, it is 1/30,000 of the size of the database, times the number of enabled
threads.
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.
To enable block change tracking:
1. Start SQL*Plus and connect to a target database with administrator privileges.
2. 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=’*';
3. 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:
1. Start SQL*Plus and connect to a target database with administrator privileges.
2. Ensure that the target database is mounted or open.
3. 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, FILENAME
FROM 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:
1. Start SQL*Plus and connect to a target database.
2. If necessary, determine the current name of the change tracking file:
SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING;
3. 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.
4. Using host operating system commands, move the change tracking file to its new
location.
5. 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.
6. Open the database:
SQL> ALTER DATABASE OPEN;
