Enabling Block Change Tracking for faster RMAN incremental backup

[Abhishek_Sinha]

Recently, SoftwareOne's SAP services team helped a customer migrate their SAP workload running on the Oracle database to the Microsoft Azure cloud. As Azure doesn't have the native capability to back up the Oracle database, and in the absence of any third-party tool being used by the customer, we decided to implement disk-level RMAN backup.

As a backup strategy, a weekly full backup was scheduled, followed by the daily incremental backups. We observed that the incremental backups were running for too long and degrading the performance. Upon further investigation, we found that the entire database was being scanned to figure out the delta which was causing this issue.

As you can see in the image above, the entire 18T of data was being scanned to determine the delta, and the actual backup was merely 161M.

In pursuit of a resolution, we came across the BCT - Block change tracking solution.

Block change tracking - description
Block change tracking (abbreviated: BCT) is a new RMAN function as of Oracle Database 10g (Enterprise Edition). Block change tracking (BCT) notably decreases the time required for incremental backups using RMAN.

When block change tracking is active, Oracle uses a block change tracking file (abbreviated: BCTF) to log which data blocks have changed since the last RMAN level 0 backup. RMAN then uses the information from the BCTF in incremental backups to read and backup only those blocks that have been changed.

However, it must be noted that, by default, after a level 0 backup, a maximum of eight incremental backups that use this feature can be performed. If you perform more than eight incremental backups between two level 0 backups, an additional configuration is required.

Prerequisites
Block change tracking is supported in the SAP environment with the following prerequisites:

• Oracle Database Release 10.2 or higher
• SAP BR*Tools as of SAP Release 7.00 patch level 15

Block change tracking - recommendations

Note the following recommendations for using BCT:

• Activate block change tracking only if you perform incremental backups using RMAN.
• Regular monitoring
  If, for some reason, the database cannot access the BCTF, block change tracking is automatically deactivated. Therefore, it is recommended that you regularly check the status of the BCTF and its use for backups.

SELECT count(1) from v$backup_datafile where used_change_tracking = 'NO';​

A normal backup strategy performs a level 0 backup (full backup) once a week and performs an incremental backup on the other days. A bitmap that contains space for seven incremental backups before the space is overwritten is sufficient for this type of backup strategy.

However, if the backup strategy assumes that more than seven incremental backups take place between two level 0 backups, the parameter _bct_bitmaps_per_file must be set to a higher value to ensure that the relevant number of bitmaps is available to save the block change tracking information and to ensure that all incremental backups can take advantage of block change tracking.

Block change tracking - administration

• Activating block change tracking      

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '<location>' REUSE;

• Deactivating block change tracking

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

This deactivates BCT and deletes the BCTF from the file system.

Block change tracking status monitoring

COLUMN STATUS FORMAT A8
COLUMN FILENAME FORMAT A60
select status, filename from V$BLOCK_CHANGE_TRACKING;

After implementing the BCT, we saw a massive improvement in the run of the RMAN incremental backup

[IMPORTANT] Procedure after restore/recovery/DB Move

After a restore/recovery, you must recreate the BCTF.
1. Deactivate BCT.
2. Reactivate BCT.
3. Execute a new level 0 backup.
This procedure is a part of the BRRECOVER function.

Conclusion:

Enabling BCT brings about a massive improvement in the run of incremental RMAN backups.