: The debut of DolphinGemma
Recently, we at SoftwareOne SAP Services team helped a customer migrate their SAP workloads running on Oracle onto Microsoft Azure Cloud. Azure does not natively support backing up the Oracle database, so since the customer did not have a third-party solution, we implemented disk-level RMAN backups.
As a backup strategy, weekly full backup was scheduled, followed by daily incremental. We observed that the incremental backup ran almost as long as the full backup itself, and the performance was severely degraded. Upon investigation, we found that the incremental backup was doing a full scan of the database to identify the delta.
As shown in the image below, a full sweep of 18T of data was being done, resulting in only 160M of data being backed up.
We found documentation on Block change tracking, which could help in this scenario.
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, you must note 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.
Performance improvement due to block change tracking:
The duration of an incremental backup is approximately proportional to the size of the database if BCT is deactivated. If BCT is activated, the duration is proportional to the number of changed blocks. If only a small portion of the blocks changes between two level 0 backups, block change tracking saves a very large amount of time.
When BCT is activated for the first time, RMAN must read all blocks for each data file during the first level 0 backup since the BCTF does not reflect the actual current block status when it is first created. RMAN can only use the information from the BCTF in the subsequent incremental backups.
By default, block change tracking is deactivated.
After enabling it in our database, we saw a massive performance improvement
The backup duration for incremental backups decreased as it was only reading the change blocks rather than the entire DB.
Prerequisites
Block change tracking is supported in the SAP environment with the following prerequisites:
Oracle Database Release 10.2 or higherSAP BR*Tools as of SAP Release 7.00 patch level 15
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;
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 to 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 your backup strategy assumes that more than seven incremental backups take place between two level 0 backups, you must set the parameter _bct_bitmaps_per_file 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.
[Important] Procedure after restore/recovery/DB move
After a restore/recovery, you must recreate the BCTF.
Deactivate BCT.Reactivate BCT.Execute a new level 0 backup.
This procedure is a part of the BRRECOVER function.
Conclusion: Implementing BCT brings about a massive performance improvement in the RMAN incremental backup.
Recently, we at SoftwareOne SAP Services team helped a customer migrate their SAP workloads running on Oracle onto Microsoft Azure Cloud. Azure does not natively support backing up the Oracle database, so since the customer did not have a third-party solution, we implemented disk-level RMAN backups.As a backup strategy, weekly full backup was scheduled, followed by daily incremental. We observed that the incremental backup ran almost as long as the full backup itself, and the performance was severely degraded. Upon investigation, we found that the incremental backup was doing a full scan of the database to identify the delta.As shown in the image below, a full sweep of 18T of data was being done, resulting in only 160M of data being backed up.We found documentation on Block change tracking, which could help in this scenario.Block change tracking – descriptionBlock 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, you must note 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.Performance improvement due to block change tracking:The duration of an incremental backup is approximately proportional to the size of the database if BCT is deactivated. If BCT is activated, the duration is proportional to the number of changed blocks. If only a small portion of the blocks changes between two level 0 backups, block change tracking saves a very large amount of time.When BCT is activated for the first time, RMAN must read all blocks for each data file during the first level 0 backup since the BCTF does not reflect the actual current block status when it is first created. RMAN can only use the information from the BCTF in the subsequent incremental backups.By default, block change tracking is deactivated.After enabling it in our database, we saw a massive performance improvementThe backup duration for incremental backups decreased as it was only reading the change blocks rather than the entire DB.PrerequisitesBlock change tracking is supported in the SAP environment with the following prerequisites:Oracle Database Release 10.2 or higherSAP BR*Tools as of SAP Release 7.00 patch level 15Block change tracking – administrationActivating 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; Block change tracking – recommendationsNote the following recommendations for using BCT:Activate block change tracking only if you perform incremental backups using RMAN.Regular monitoringIf, for some reason, the database cannot access the BCTF, block change tracking is automatically deactivated. Therefore, it is recommended to 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 your backup strategy assumes that more than seven incremental backups take place between two level 0 backups, you must set the parameter _bct_bitmaps_per_file 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.[Important] Procedure after restore/recovery/DB moveAfter a restore/recovery, you must recreate the BCTF.Deactivate BCT.Reactivate BCT.Execute a new level 0 backup.This procedure is a part of the BRRECOVER function.Conclusion: Implementing BCT brings about a massive performance improvement in the RMAN incremental backup. Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
