The block change tracking (BCT)
feature for incremental backups improves incremental backup performance
by recording changed blocks in each datafile in a block change tracking
file. This file is a small binary file called block change
tracking (BCT) file stored in the database area. RMAN tracks changed
blocks as redo is generated.If we enable block change tracking, then
RMAN uses the change tracking file(BCT) to identify changed blocks for
an incremental backup, thus avoiding the need to scan every block in the
datafile. RMAN only uses block change tracking when the incremental
level is greater than 0 because a level 0 incremental backup includes
all blocks.
Enable block change tracking (BCT)
SQL>
alter database enable block change tracking using file 'C:\app\neerajs\admin\noida\bct.dbf' ;
When data blocks change, shadow
processes track the changed blocks in a private area of memory at the
same time they generate redo . When a commit is issued, the BCT
information is copied to a shared area in Large Pool called 'CTWR dba
buffer' . At the checkpoint, a new background process, Change Tracking
Writer (CTWR) , writes the information from the buffer to the
change-tracking file . If contention for space in the CTWR dba buffer
occurs, a wait event called , 'Block Change Tracking Buffer Space' is
recorded. Several causes for this wait event are poor I/O performance on
the disk where the change-tracking file resides , or the CTWR dba
buffer is too small to record the number of concurrent block changes .By
default, the CTWR process is disabled because it can introduce some
minimal performance overhead on the database.
The v$block_change_tracking
views contains the name and size of the block change tracking file
plus the status of change tracking: We can check by the below command :
SQL>
select filename, status, bytes from v$block_change_tracking;
To check whether the block change tracking file is being used or not, use the below command .
SQL>
select file#, avg(datafile_blocks), avg(blocks_read), avg(blocks_read/datafile_blocks) * 100 as "% read for backup" from v$backup_datafile where incremental_level > 0 and used_change_tracking = 'YES' group by file# order by file# ;
To
disable Block Change Tracking (BCT) issue the below command
:
SQL>
alter database disable block change tracking ;
Estimating Size of the Change Tracking File on Disk
The size of the change
tracking file is proportional to the size of the database and the number
of enabled threads of redo. 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. Note, however, the following two factors that may cause the
file to be larger than this estimate suggests:
-
To avoid overhead of allocating space as your database grows, the
change tracking file size starts at 10MB, and new space is allocated in
10MB incremenents. Thus, for any database up to approximately 300GB the
file size is no smaller than 10MB, for up to approximately 600GB the
file size is no smaller than 20MB, and so on.
-
For each datafile, a minimum of 320K of space is allocated in the
change tracking file, regardless of the size of the file. 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.
阅读(1527) | 评论(0) | 转发(0) |