Oracle RMAN was able to take incremental backups already in 9i. However, prior to introduction of Oracle 10g block change tracking (BCT), RMAN had to scan the whole datafile to and filter out the blocks that were not changed since base incremental backup and overhead or incremental backup was as high as full backup.
Oracle 10g new feature, block change tracking, minimizes number of blocks RMAN needs to read to a strict minimum. With block change tracking enabled RMAN accesses on disk only blocks that were changed since the latest base incremental backup.
This feature is widely known in the world of Oracle database administrators. However, hardly anything is available on internal implementation of block change tracking. This makes it difficult to evaluate the impact of enabling BCT in Oracle databases and quantify performance overhead.
Without BCT enabled or in cases when change tracking information cannot be used, RMAN has to read every block in the datafile during incremental backup. Each block contains last system change number (SCN) of its last modification. The block is copied only if its SCN is higher or equal to the base backup SCN. To be precise, the backup SCN is a checkpoint SCN that was made right before the backup. Since, usually, only handful of blocks is changed between incremental backups, RMAN does a lot of useless work reading the blocks not required for backup.
Block change tracking provides a way to identify the blocks required for backup without scanning the whole datafile. After that RMAN need only read blocks that are really required for this incremental backup.
However, improvement in incremental backup requires some sacrifice during normal database operations. According to Oracle this performance overhead is supposed to be minimal. Nevertheless, by default change tracking is disabled. Oracle 10g introduces a new special background process – Check Tracking Writer (CTWR). This process takes care of logging information about changed blocks in block change tracking file.
Extended SQL tracing using event 10046 was used extensively on foreground sessions as well as background processes such as DBWx, LGWR, CKPT, and CTWR.
CHANGE TRACKING INSIDE ORACLE INSTANCE
There is a new special process in Oracle 10g – Change Tracking WRiter (CTWR). As name suggests the job of this process is to write to the block change tracking file. In normal Oracle operations there is no other process that is writing to it. RMAN shadow process reads from as well as writes to the change tracking file during incremental backups.
Any process in Oracle can read from change tracking file. When user session queries X$KRC% views, it access BCT file behind the scenes. Shadow process itself accesses CTWR file without communications to CTWR process.
BLOCK CHANGE TRACKING FILE
BCT file is one per database. In case of RAC database, change tracking file is shared amongst all instances. Thus, BCT file must be on shared storage. By default, BCT file is created in the location defined by parameter DB_CREATE_FILE_DEST as Oracle managed file (OMF). If parameter is not defined then location is platform specific and, usually, somewhere within
ORACLE_HOME.
View V$BLOCK_CHANGE_TRACKING can be queried to find out the status of change tracking in the database.
NON-CDB:
export ORACLE_HOME=/u01/oracle/product/11.2.0.4/db
export ORACLE_SID=asrblg
$ORACLE_HOME/bin/sqlplus / as sysdba
select * from v$block_change_tracking;
show parameter bct
CDB:
export ORACLE_HOME=/u01/oracle/product/19/db
export ORACLE_SID=asrblg
$ORACLE_HOME/bin/sqlplus / as sysdba
select * from v$block_change_tracking;
show parameter bct
The block change tracking file block size is controlled by hidden parameter “_bct_file_block_size”. On Linux platform the BCT block size is by default 512 bytes. The default might be different on other platforms.
HIDDEN PARAMETERS
• _bct_public_dba_buffer_size – total size of all public change tracking dba buffers, in
• _bct_initial_private_dba_buffer_size – initial number of entries in the private change tracking dba buffers
• _bct_bitmaps_per_file – number of bitmaps to store for each datafile
• _bct_file_block_size – block size of change tracking file, in bytes
• _bct_file_extent_size – extent size of change tracking file, in bytes
• _bct_chunk_size – change tracking datafile chunk size, in bytes
• _bct_crash_reserve_size – change tracking reserved crash recovery SGA space, in bytes
• _bct_buffer_allocation_size – size of one change tracking buffer allocation, in bytes
• _bct_buffer_allocation_max – maximum size of all change tracking buffer allocations, in bytes
• _bct_buffer_allocation_min_extents – mininum number of extents to allocate per buffer allocation
• _bct_fixtab_file – change tracking file for fixed tables
Update container database BCT parameters if they do not meet the recommendations from during DB Upgrade event to 19c.
export ORACLE_HOME=/u01/oracle/product/19/db
export ORACLE_SID=asrblg
$ORACLE_HOME/bin/sqlplus / as sysdba
alter system set "_bct_public_dba_buffer_maxsize"=<value> scope=spfile sid='*';
alter system set "_bct_buffer_allocation_max"=<value> scope=spfile sid='*';
alter system set "_bct_public_dba_buffer_size"=<value> scope=spfile sid='*';
alter system set large_pool_size=<value> scope=spfile sid='*';
Enable Block Change Tracking.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DATA_DG1';
CTWR (Change Tracking writer process)
SQL> select * from v$sgastat where name like '%CTWR%';
SQL> select sid,program,status from v$session where program like '%CTWR%';
Disable block change Tracking.
SQL> alter database disable block change tracking;
SQL> select sid,program,status from v$session where program like '%CTWR%';
