RMAN-BLOCK Change Tracking-CSDN博客

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: