Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
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.
Table 2-2 describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up.
Table 2-2 Criteria to Determine an Identical File
Type of File | Criteria to Determine an Identical File |
---|---|
Datafile | The datafile must have the same DBID, checkpoint SCN, creation SCN, and RESETLOGS SCN and time as a datafile already in a backup. The datafile must be offline-normal, read-only, or closed normally. |
Archived redo log | Same thread, sequence number, and RESETLOGS SCN and time. |
Backup set | Same backup set recid and stamp. |
If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. However, RMAN must do further checking to determine whether to skip the file, 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.
Table 2-3 describes the algorithm that backup optimization uses when determining whether to skip the backup of an identical file.
Table 2-3 Backup Optimization Algorithm
For an Identical ... | Backup Optimization Algorithm |
---|---|
Datafile | With a recovery window-based retention policy:
For backups to tape, RMAN takes another backup of a file, even if a backup of an identical file exists, if the most recent backup is older than the configured recovery window. This is done to allow media to be recycled after the media expires. For backups to disk, RMAN skips taking the backup if an identical file is available from a backup on disk, even if that backup is older than the beginning of the recovery window. The retention policy causes RMAN to retain the old backup for as long as it is needed. With a redundancy-based retention policy: RMAN sets r
RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified. |
Archived log | By default, n=1 . RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):
RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified. |
Backup set | By default, n=1 . RMAN searches for other values of n in this order of precedence (that is, values higher on the list override values lower on the list):
RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified. |
For example, assume that at 9 a.m. you back up three copies of all existing archived logs to tape:
BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;
Later, you enable the following configuration setting in preparation for another backup:
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 4; CONFIGURE BACKUP OPTIMIZATION ON;
Then, you run the following archived log backup at noon:
BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
In this case, the BACKUP
...
COPIES
setting overrides the CONFIGURE
...
COPIES
setting, so RMAN sets n
=2
. RMAN skips the backup of a log only if at least two copies of the log exist on the sbt
device. Because three copies of each log exist on sbt
of all the logs generated before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up two copies of all logs generated after 9 a.m. because these logs have not yet been backed up to tape.
At this point, three copies of the logs created before 9 a.m. exist on tape, and two copies of the logs created after 9 a.m. exist on tape. Assume that you run the following backup at 3 p.m.:
RUN { SET BACKUP COPIES 3; BACKUP DEVICE TYPE sbt ARCHIVELOG ALL; }
In this case, RMAN sets n
=3
and so will not back up the logs created before 9 a.m. because three copies already exist on tape. However, only two copies of the logs created after 9 a.m. exist on tape, so RMAN does not optimize backups of these logs. Hence, RMAN backs up three copies of the logs created after 9 a.m.
Backup optimization is used when the following conditions are true:
The CONFIGURE
BACKUP
OPTIMIZATION
ON
command has been run to enable backup optimization.
You run BACKUP
DATABASE
, BACKUP
ARCHIVELOG
with ALL
or LIKE
options, or BACKUP
BACKUPSET
ALL.
Only one type of channel is allocated, that is, you do not mix channels of type DISK
and sbt
in the same backup command.
For example, assume that you run these commands:
BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL;
If none of these files has changed since the last backup, then RMAN does not back up the files again, nor signal an error if it skips all files specified in the command.
To override backup optimization and back up all files whether or not they have changed, specify the FORCE
option on the BACKUP
command. For example:
BACKUP DEVICE TYPE sbt BACKUPSET ALL FORCE;
To disable backup optimization on a persistent basis, use the following command:
RMAN> CONFIGURE BACKUP OPTIMIZATION OFF;
Backup optimization is not always applied when backing up to SBT. The exceptions to normal backup optimization behavior for recovery window-based and redundancy-based retention policies are described in the following sections.
Note: Use caution when enabling backup optimization if you use a media manager with its own internal expiration policy. RunCROSSCHECK periodically to synchronize the RMAN repository with the media manager. Otherwise, RMAN may skip backups due to optimization without recognizing that the media manager has discarded backups stored on tape. |
If backup optimization is enabled, and if a recovery window retention policy is in effect, then when performing SBT backups RMAN always backs up datafiles whose most recent backup is older than the recovery window. For example, assume that:
Today is February 21.
The recovery window is 7 days.
The most recent backup of tablespace tools
to tape is January 3.
Tablespace tools
is read-only.
On February 21, when you issue a command to back up tablespace tools
to tape, RMAN backs it up even though it did not change after the January 3 backup (because it is read-only). RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window.
This behavior allows the media manager to expire old tapes. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools
indefinitely. By making a more recent backup of tablespace tools
on February 21, RMAN allows the media manager to expire the tape containing the obsolete January 3 backup.
Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only datafiles to SBT when there are r
+ 1 backups of the files, where r
is set in CONFIGURE
RETENTION
POLICY
TO
REDUNDANCY
r
.
For example, assume that you enable backup optimization and set the following retention policy:
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
With these settings, RMAN only skips backups when three identical files are already backed up. Also assume that you have never backed up the users
tablespace, which is read/write, and that you perform the actions described in Table 2-4 over the course of the week.
Table 2-4 Effect of Redundancy Setting on Backup Optimization
Day | Action | Result | Redundant Backup |
---|---|---|---|
Monday | Take tablespace users offline normal. |
||
Tuesday | BACKUP DATABASE |
The users tablespace is backed up. |
|
Wednesday | BACKUP DATABASE |
The users tablespace is backed up. |
|
Thursday | BACKUP DATABASE |
The users tablespace is backed up. |
Tuesday backup |
Friday | BACKUP DATABASE |
The users tablespace is not backed up. |
Tuesday backup |
Saturday | BACKUP DATABASE |
The users tablespace is not backed up. |
Tuesday backup |
Sunday | DELETE OBSOLETE |
The Tuesday backup is deleted. | |
Monday | BACKUP DATABASE |
The users tablespace is backed up. |
Wednesday backup |
The backups on Tuesday, Wednesday, and Thursday back up the offline users
tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). The Friday and Saturday backups do not back up the users
tablespace because of backup optimization. Note that the Tuesday backup of users
is obsolete beginning on Thursday.
On Sunday, you delete all obsolete backups, which removes the Tuesday backup of users
. The Tuesday backup is obsolete because of the retention policy setting. The whole database backup on Monday then backs up the users
tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). In this way, you can recycle your tapes over time.