RMAN Backup Optimization
If you enable backup optimization, then the BACKUP command skips backing up files when the identical file has already been backed up to the specified device type. If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. RMAN must do further checking to determine whether to skip the file, however, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type.
RMAN uses backup optimization when the following conditions are true:
- The CONFIGURE BACKUP OPTIMIZATION ON command has been run to enable backup optimization.
- You run BACKUP DATABASE, BACKUP ARCHIVE LOG with ALL or LIKE options, or BACKUP BACK UPSET ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES, or BACKUP DATA FILE COPY.
Caution: If you are using a fast recovery area, then you should not run your database with the retention policy disabled. If files are never considered obsolete, then a file can only be deleted from the fast recovery area if it has been backed up to some other disk location or to a tertiary storage device such as tape. This action is likely to use all of the space in your recovery area, which interferes with the normal operation of your database.
When the Archived Redo Log Deletion Policy Is Disabled
By default, there is no archived redo log deletion policy and this is why the archive redo log policy is set to the NONE clause. In this particular case, the fast recovery area considers archived redo log files in the recovery area as eligible for deletion if they have been backed up at least once to disk or SBT or the logs are obsolete according to the backup retention policy. The backup retention policy considers logs obsolete only if the logs are not needed by a guaranteed restore point and the logs are not needed by Oracle Flashback Database. Archived redo logs are needed by Flashback Database if the logs were created later than SYS DATE-‘DB_FLASHBACK_RETENTION_TARGET’.
When the Archived Redo Log Deletion Policy Is Enabled
You can use the CONFIGURE ARCHIVE LOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPE command to enable an archived log deletion policy. This configuration specifies that archived logs are eligible for deletion only when the specified number of archived log backups exist on the specified device type. If the deletion policy is configured with the BACKED UP integer TIMES clause, then a BACKUP ARCHIVE LOG command copies the logs unless integer backups already exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVE LOG command skips the logs.
In this way, the archived log deletion policy functions as a default NOT BACKED UP integer TIMES clause on the BACKUP ARCHIVE LOG command. You can override the deletion policy by specifying the FORCE option on the BACKUP command. The archived log deletion policy also has options specific to a Data Guard environment. For example, if you specify the APPLIED ON STANDBY clause, then RMAN can delete logs after they have been applied at all mandatory remote destinations. If you specify SHIPPED TO STANDBY, then RMAN can delete logs when they have been transferred to all mandatory standby destinations.
Using Block Change Tracking to Improve Incremental Backup Performance
The block change tracking feature for incremental backups improves backup performance by recording changed blocks for each data file.
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 data file that it is backing up. Block change tracking is disabled by default.
Nevertheless, the benefits of avoiding full data file 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 does not change 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 data files 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 eight most recent backups.
After the maximum of eight 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 data file. 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 eight-bitmap limit when developing your incremental backup strategy. For example, if you make a level 0 database backup followed by seven differential incremental backups, then the block change tracking file now includes eight 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 over written 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 that 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.
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 megabytes. New space is allocated in 10 MB increments. Thus, for any database up to approximately 300 gigabytes, the file size is no smaller than 10 MB, for up to approximately 600 gigabytes the file size is no smaller than 20 megabytes, and so on.
- For each data file, a minimum of 320 kilobytes of space is allocated in the block change tracking file, regardless of the size of the data file. Thus, if you have a large number of relatively small data files, the change tracking file is larger than for databases with a smaller number of larger data files containing the same data.