Skip Headers
Oracle® Database Backup and Recovery User's Guide
11g Release 1 (11.1)

Part Number B28270-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

7 RMAN Backup Concepts

This chapter describes the general concepts that you need to understand to make any type of RMAN backups. This chapter contains the following topics:

Consistent and Inconsistent RMAN Backups

The RMAN command for making backups is BACKUP. The RMAN BACKUP command supports backing up the following types of files:

Although the database depends on other types of files, such as network configuration files, password files, and the contents of the Oracle home, you cannot back up these files with RMAN. Likewise, some features of Oracle, such as external tables, may depend upon files other than the datafiles, control files, and redo log. RMAN cannot back up these files. Use some non-RMAN backup solution for any files not in the preceding list.

When you execute the BACKUP command in RMAN, the output is always either one or more backup sets or one or more image copies. A backup set is an RMAN-specific proprietary format, whereas an image copy is a bit-for-bit copy of a file. By default, RMAN creates backup sets.

Consistent Backups

You can use the BACKUP command to make consistent and inconsistent backups of the database. A consistent backup occurs when the database is in a consistent state. A database is in a consistent state after being shut down with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown guarantees that all redo has been applied to the datafiles. If you mount the database and take a backup at this point, then you can restore the database backup later and open it without performing media recovery.

Inconsistent Backups

Any database backup of that is not consistent is an inconsistent backup. A backup made when the database is open is inconsistent, as is a backup made after an instance failure or SHUTDOWN ABORT command. When a database is restored from an inconsistent backup, Oracle must perform media recovery before the database can be opened, applying any pending changes from the redo logs.


RMAN does not permit you to make inconsistent backups when the database is in NOARCHIVELOG mode. If you employ user-managed backup techniques for a NOARCHIVELOG database, then you must not make inconsistent backups of this database.

As long as the database runs in ARCHIVELOG mode, and you back up the archived redo logs and datafiles, inconsistent backups can be the foundation for a sound backup and recovery strategy. Inconsistent backups offer superior availability because you do not have to shut down the database to make backups that fully protect the database.

Online Backups and Backup Mode

When performing a user-managed backup of an online tablespace or database, an operating system utility such as cp or dd may read a block at the same time that database writer is updating a block. In this case, the block copied to the backup media may have been updated in its first half, while the second half contains older data. This type of logical corruption is known as a fractured block, that is, a block that is not consistent with respect to an SCN. If this backup needs to be restored later, and if the block requires recovery, then recovery will fail because the block is not usable.

When performing a user-managed online backup, you must place your datafiles into backup mode with the ALTER DATABASE or ALTER TABLESPACE statement with the BEGIN BACKUP clause. When a tablespace is in backup mode, the database writes the before image for an entire block to the redo stream before modifying a block. The database also records changes to the block in the online redo log. Backup mode also freezes the checkpoint in the header of the file until the file is removed from backup mode. Oracle Database performs this safeguard because it cannot guarantee that a third-party backup tool will copy the file header before copying the data blocks.

Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks. During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block. If the same fracture is found, then the block is considered permanently corrupt. Also, RMAN does not need to freeze the file header checkpoint because it knows the order in which the blocks will be read, which enables it to capture a known good checkpoint for the file.

See Also:

Chapter 27, "Making User-Managed Backups of Online Tablespaces and Datafiles" to learn how to back up online tablespaces when not using RMAN

Backup Sets

When you execute the BACKUP command in RMAN, you create one or more backup sets or image copies. By default, RMAN creates backup sets regardless of whether the destination is disk or a media manager.

This section contains the following topics:

Backup Sets and Backup Pieces

RMAN can store backup data in a logical structure called a backup set, which is the smallest unit of an RMAN backup. A backup set contains the data from one or more datafiles, archived redo logs, or control files or server parameter file. Backup sets, which are only created and accessed through RMAN, are the only form in which RMAN can write backups to media managers such as tape drives and tape libraries.

A backup set contains one or more binary files in an RMAN-specific format. This file is known as a backup piece. A backup set can contain multiple datafiles. For example, you can back up ten datafiles into a single backup set consisting of a single backup piece. In this case, RMAN creates one backup piece as output. The backup set contains only this backup piece.

If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN produces a multisection backup. This is a backup of a single large file, produced by multiple channels in parallel, each of which produces one backup piece. Each backup piece contains one file section of the file being backed up.

RMAN only records backup sets in the repository that complete successfully. There is no such thing as a partial backup set.

See Also:

Chapter 8, "Backing Up the Database" to learn how to back up the database

Compression for Backup Sets

When backing up datafiles to backup sets, RMAN can use unused block compression to skip datafile blocks. RMAN always skips blocks that have never been used. Under certain conditions, which are listed in the BACKUP AS BACKUPSET entry in Oracle Database Backup and Recovery Reference, RMAN also skips blocks that are not currently used. Thus, datafile backup sets are typically smaller than datafile copies and take less time to write. Unused block compression is fundamental to how RMAN writes datafiles into backup pieces and cannot be disabled.

RMAN also supports binary compression of backup sets. The supported algorithms are BZIP2 (default) and ZLIB. The BZIP2 algorithm is optimized for maximum compression, whereas the ZLIB algorithm is optimized for CPU efficiency. BZIP2 consumes more CPU resource than ZLIB, but will usually produce more compact backups. Note that the COMPATIBLE initialization parameter must be set to 11.0.0 or higher for ZLIB compression.

RMAN compresses the backup set contents before writing them to disk. No extra uncompression steps are required during recovery when you use RMAN compression.

In backup undo optimization, RMAN excludes undo not needed for recovery of a backup, that is, for transactions have already been committed. You can enable and disable backup optimization, but backup undo optimization is built-in behavior.

Encryption for Backup Sets

RMAN supports backup encryption for backup sets. You can use wallet-based transparent encryption, password-based encryption, or both. You can use the CONFIGURE ENCRYPTION command to configure persistent transparent encryption. Use the SET ENCRYPTION, command at the RMAN session level to specify password-based encryption.

To create encrypted backups on disk with RMAN, the database must use the Advanced Security Option. The Oracle Secure Backup SBT is the only supported interface for making encrypted RMAN backups directly to tape. Note that the Advanced Security Option is not required when making encrypted backups to the Oracle Secure Backup SBT.

Filenames for Backup Pieces

You can either let RMAN determine a unique name for backup pieces or use the FORMAT clause to specify a name. If you do not specify the FORMAT parameter, then RMAN automatically generates a unique filename with the %U substitution variable in the default backup location. An example of an SBT backup piece name generated by %U is 12i1nk47_1_1. An example of a backup piece on disk is as follows:


The FORMAT clause supports substitution variables other than %U for generating unique filenames. For example, you can use %d to generate the name of the database, %I for the DBID, %t for the timestamp, and so on.

You can specify up to four FORMAT parameters. If you specify multiple FORMAT parameters, then RMAN uses the multiple FORMAT parameters only when you specify multiple copies. You can create multiple copies by using the BACKUP ... COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES commands.


If you use a media manager, then check your vendor documentation for restrictions on FORMAT such as the size of the name, the naming conventions, and so on.

See Also:

Number and Size of Backup Pieces

By default a backup set contains one backup piece. To restrict the size of each backup piece, specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. This option limits backup piece size to the specified number of bytes. If the total size of the backup set is greater than the specified backup piece size, then RMAN creates multiple physical pieces to hold the backup set contents.

You can use this option for media managers that cannot manage a backup piece that spans more than one tape. For example, if a tape can hold 10 GB, but the backup set being created must hold 80 GB of data, then you must instruct RMAN to create backup pieces of 10 GB, small enough to fit on the tapes used with the media manager. In this case, the backup set media will consist of eight tapes. Media managers supporting SBT 2.0 can return a value to RMAN indicating the largest supported backup piece size, which RMAN will use in planning backup activities.

Note that if you specify the SECTION SIZE parameter on the BACKUP command, then RMAN can create a multisection backup. In this case, a single backup set can contain multiple backup pieces, each containing a file section. The purpose of multisection backups is to enable multiple channels to back up a large file in parallel.

Number and Size of Backup Sets

You use the backupSpec clause of the BACKUP command to specify the objects to be backed up. Each backupSpec clause produces at least one backup set.

The total number and size of backup sets depends for the most part on an internal RMAN algorithm. However, you can influence RMAN behavior with the MAXSETSIZE parameter in the CONFIGURE or BACKUP command. By limiting the size of the backup set, the parameter indirectly limits the number of files in the set and can possibly force RMAN to create additional backup sets. Also, you can specify BACKUP ... FILESPERSET to specify the maximum number of files in each backup set.

See Also:

Multiplexed Backup Sets

When creating backup sets, RMAN can simultaneously read multiple files from disk and then write their blocks into the same backup set. For example, RMAN can read from two datafiles simultaneously, and then combine the blocks from these datafiles into a single backup piece. The combination of blocks from multiple files is called backup multiplexing. Image copies, by contrast, are never multiplexed.


If RMAN creates a multisection backup of a datafile, then the datafile will not be multiplexed with any other datafile or file section.

As Figure 7-1 illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece. This backup piece contains the intermingled data blocks of the three input datafiles.

Figure 7-1 Datafile Multiplexing

Description of Figure 7-1 follows
Description of "Figure 7-1 Datafile Multiplexing"

RMAN multiplexing is determined by several factors. For example, the FILESPERSET parameter of the BACKUP command determines how many datafiles to put in each backup set. The MAXOPENFILES parameter of ALLOCATE CHANNEL or CONFIGURE CHANNEL defines how many datafiles RMAN can read from simultaneously. The basic multiplexing algorithm is as follows:

  • Number of files in each backup set

    This number is the minimum of the FILESPERSET setting and the number of files read by each channel. The FILESPERSET default is 64.

  • The level of multiplexing

    This is the number of input files simultaneously read and then written into the same backup piece. The level of multiplexing is the minimum of MAXOPENFILES and the number of files in each backup set. The MAXOPENFILES default is 8.

Suppose that you back up 12 datafiles with one channel. The number of files in each backup set is 4. The level of multiplexing is the lesser of this number and 8. Thus, the channel simultaneously writes blocks from 4 datafiles into each backup piece.

Now suppose that you back up 50 datafiles with one channel. The number of files in each backup set is 50. The level of multiplexing is the lesser of this number and 8. Thus, the channel simultaneously writes blocks from 8 datafiles into each backup piece.

RMAN multiplexing of backup sets is different from media manager multiplexing. One type of media manager multiplexing occurs when the media manager writes the concurrent output from multiple RMAN channels to a single sequential device. Another type occurs when a backup mixes database files and non-database files on the same tape.


Oracle recommends that you never use media management multiplexing for RMAN backups.

See Also:

Proxy Copies

During a proxy copy, RMAN turns over control of the data transfer to a media manager that supports this feature. Proxy copy can only be used with media managers that support it and cannot be used with channels of type DISK. The PROXY option of the BACKUP command specifies that a backup should be a proxy copy.

For each file that you attempt to back up with the BACKUP PROXY command, RMAN queries the media manager to determine whether it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN backs the file up as if the PROXY option had not been used. (Use the PROXY ONLY option to force RMAN to fail if a proxy copy cannot be performed.)

Note that control files are never backed up with proxy copy. If the PROXY option is specified on an operation backing up a control file, then it is silently ignored for the purposes of backing up the control file.

See Also:

Image Copies

An image copy is an exact copy of a single datafile, archived redo log file, or control file. Image copies are not stored in an RMAN-specific format. They are identical to the results of copying a file with operating system commands. RMAN can use image copies during RMAN restore and recover operations, and you can also use image copies with non-RMAN restore and recovery techniques.

RMAN-Created Image Copies

To create image copies and have them recorded in the RMAN repository, you run the RMAN BACKUP AS COPY command. Alternatively, you can configure the default backup type for disk as image copies. A database server session is used to create the copy. The server session also performs actions such as validating the blocks in the file and recording the image copy in the RMAN repository.

As with backup pieces, FORMAT variables are also used to specify the names of image copies. The default format %U, which was explained in "Filenames for Backup Pieces", is defined differently for image copies. The following example shows name for datafile 2 generated by %U:


When creating image copies, you can also name the output copies with the DB_FILE_NAME_CONVERT parameter of the BACKUP command. This parameter works identically to the DB_FILE_NAME_CONVERT initialization parameter. Pairs of filename prefixes are provided to change the names of the output files. If a file is not converted by any of the pairs, then RMAN uses the FORMAT specification; if no FORMAT is specified, then RMAN uses the default format %U.

Example 7-1 copies the datafiles whose filename is prefixed with /maindisk/oradata/users so that they are prefixed with /backups/users_ts.

Example 7-1 Specifying Filenames with DB_FILE_NAME_CONVERT

  DB_FILE_NAME_CONVERT ('/maindisk/oradata/users',

If you run a RESTORE command, then by default RMAN restores a datafile or control file to its original location by copying an image copy backup to that location. Image copies are chosen over backup sets because of the extra overhead of reading through an entire backup set in search of files to be restored.

If you need to restore and recover a current datafile, and if you have an image copy available on disk, then you do not need to have RMAN copy the image copy back to its old location. Instead, you can use the image copy in place as a replacement for the datafile to be restored. "Performing Complete Recovery of a Datafile After Switching to a Copy" explains how to perform this task.

See Also:

User-Managed Image Copies

RMAN can use image copies created by mechanisms outside of RMAN, such as native operating system file copy commands or third-party utilities that leave image copies of files on disk. This type of copy is known as a user-managed backup or operating system backup.

You can use the CATALOG command to inspect an existing image copy and enter its metadata into the RMAN repository. However, the CATALOG command does not do the following:

  • Read all blocks in the datafile copy to insure there are no corruptions

  • Guarantee that the image copy was correctly made in backup mode

After you catalog these files, you can use them with the RESTORE or SWITCH commands just as you can for RMAN-generated image copies.

Some sites store their datafiles on mirrored disk volumes, which permit the creation of image copies by breaking a mirror. After you have broken the mirror, you can notify RMAN of the existence of a new user-managed copy, thus making it eligible for a backup. You must notify RMAN when the copy is no longer available by using the CHANGE ... UNCATALOG command.

Multiple Copies of RMAN Backups

In RMAN, you can make multiple, identical copies of backups in the following ways:

Duplexed Backup Sets

When backing up datafiles, archived redo log files, server parameter files, and control files into backup pieces, RMAN can create a duplexed backup set, producing up to four identical copies of each backup piece in the backup set on different backup destinations with one BACKUP command. Duplexing is not supported for backup operations that produce image copies.

You can use the COPIES parameter in the CONFIGURE, SET, or BACKUP commands to specify duplexing of backup sets when using the BACKUP command. RMAN can duplex backups to either disk or tape, but cannot duplex backups to tape and disk simultaneously. When backing up to tape, ensure that the number of copies does not exceed the number of available tape devices.

The FORMAT parameter of the BACKUP command specifies the destinations for duplexed backups. The following example creates 3 copies of the backup of datafile 7:

  FORMAT '/disk1/%U','?/oradata/%U','?/%U';

RMAN places the first copy of each backup piece in /disk1, the second in ?/oradata, and the third in the Oracle home. Note that RMAN does not produce 3 backup sets, each with a different unique backup set key. Rather, RMAN produces one backup set with a unique key, and generates 3 identical copies of each backup piece in the set.

Backups of Backups

You can use the BACKUP command to back up existing backup sets and image copies.

Backups of Backup Sets

The RMAN BACKUP BACKUPSET command backs up backup sets that were created on disk. The command is a useful way to spread backups among multiple media.

If RMAN discovers that one copy of a backup set is corrupted or missing, then it searches for other copies of the same backup set. This behavior is similar to the behavior of RMAN when backing up archived redo logs that exist in multiple archiving destinations.

Example 7-2 shows how you might run the BACKUP command weekly as part of the production backup schedule. In this way, you ensure that all your backups exist on both disk and tape.

Example 7-2 Backing Up Backup Sets to Tape

  BACKUPSET ALL; # copies backup sets on disk to tape


Backups to sbt that use automatic channels require that you first run the CONFIGURE DEVICE TYPE sbt command.

You can also use BACKUP BACKUPSET to manage backup space allocation. Example 7-3 backs up backup sets that were created more than a week ago from disk to tape, and then deletes them from disk.

Example 7-3 Managing Space Allocation


Note that DELETE INPUT here is equivalent to DELETE ALL INPUT: RMAN deletes all existing copies of the backup set. If you duplexed a backup to four locations, then RMAN deletes all four copies of the pieces in the backup set.

Backups of Image Copies

You can use the BACKUP COPY OF command to back up existing image copies of database files either as backup sets or as image copies. When using this command, an image copy of every datafile specified in the command must already exist. If there are multiple copies of a datafile, then the latest one is used. If you specify a tablespace or the whole database, then RMAN issues an error if there are datafiles in the database or tablespace for which there are no image copy backups.

Control File and Server Parameter File Autobackups

Having recent backups of your control file and server parameter file is extremely valuable in many recovery situations. To increase the likelihood that you will have such backups, the database supports control file and server parameter file autobackups. The autobackup occurs independently of any backup of the current control file explicitly requested as part of your BACKUP command.

With a control file autobackup, RMAN can recover the database even if the current control file, recovery catalog, and server parameter file are inaccessible. Because the path used to store the autobackup follows a well-known format, RMAN can search for and restore the server parameter file from that autobackup. After you have started the instance with the restored server parameter file, RMAN can restore the control file from the autobackup. After you mount the control file, use the RMAN repository in the mounted control file to restore the datafiles.

When RMAN Performs Control File Autobackups

If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the control file and the current server parameter file (if used to start up the database) at the end of a successful BACKUP command. If the database runs in ARCHIVELOG mode, RMAN makes control file autobackups when a structural change to the database affects the contents of the control file.

How RMAN Performs Control File Autobackups

The first channel allocated during the backup job creates the autobackup and places it into its own backup set. For autobackups after database structural changes, the server process associated with the structural change makes the backup.

If a server parameter file is in use by the database, then RMAN backs it up in the same backup set as the control file autobackup. After the autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log located in the Automatic Diagnostic Repository (ADR).


Control file autobackups are never duplexed.

The control file autobackup filename has a default format of %F for all device types, so that RMAN can determine the file location and restore it without a repository. You can specify a different format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command, but all autobackup formats must include the %F variable. If you do not use the default format, then during disaster recovery you must specify the format that was used to generate the autobackups. Otherwise, RMAN cannot restore the autobackup.

Incremental Backups

By default, RMAN makes full backups. A full backup of a datafile includes every allocated block in the file being backed up. A full backup of a datafile can be an image copy, in which case every data block is backed up. It can also be stored in a backup set, in which case datafile blocks not in use may be skipped.

A full backup is the default type of RMAN backup. A full backup has no effect on subsequent incremental backups and is not considered a part of an incremental backup strategy. Image copies are always full backups because they include every data block in a datafile. A backup set is by default a full backup because it can potentially include every data block in a datafile, although unused block compression means that blocks never used are excluded and, in some cases, currently unused blocks are excluded (see "Compression for Backup Sets").

In contrast to a full backup, an incremental backup copies only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database. A full backup cannot be part of an incremental backup strategy; that is, it cannot be the parent for a subsequent incremental backup.

Multilevel Incremental Backups

RMAN can create multilevel incremental backups. Each incremental level is denoted by a value of 0 or 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. You can create a level 0 database backup as backup sets or image copies.

The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy. Thus, a full backup is the parent of incremental backups whose level is greater than 0.

A level 1 incremental backup can be either of the following types:

Incremental backups are differential by default.


Cumulative backups are preferable to differential backups when recovery time is more important than disk space, because fewer incremental backups need to be applied during recovery.

The size of the backup file depends solely upon the number of blocks modified, the incremental backup level, and the type of incremental (differential or cumulative).

Differential Incremental Backups

In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent incremental backup at level 1 (cumulative or differential) or level 0. For example, in a differential level 1 backup, RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, then RMAN copies all blocks changed since the base level 0 backup.

If no level 0 backup is available, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN behaves as it did in previous releases, by generating a level 0 backup.

Figure 7-2 Differential Incremental Backups

Description of Figure 7-2 follows
Description of "Figure 7-2 Differential Incremental Backups"

In the example shown in Figure 7-2, the following occurs each week:

  • Sunday

    An incremental level 0 backup backs up all blocks that have ever been in use in this database.

  • Monday - Saturday

    On each day from Monday through Saturday, a differential incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level 1 or 0. The Monday backup copies blocks changed since Sunday level 0 backup, the Tuesday backup copies blocks changed since the Monday level 1 backup, and so forth.

Cumulative Incremental Backups

In a cumulative level 1 backup, RMAN backs up all blocks used since the most recent level 0 incremental backup. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups because they duplicate the work done by previous backups at the same level.

Figure 7-3 Cumulative Incremental Backups

Description of Figure 7-3 follows
Description of "Figure 7-3 Cumulative Incremental Backups"

In the example shown in Figure 7-3, the following occurs each week:

  • Sunday

    An incremental level 0 backup backs up all blocks that have ever been in use in this database.

  • Monday - Saturday

    A cumulative incremental level 1 backup copies all blocks changed since the most recent level 0 backup. Because the most recent level 0 backup was created on Sunday, the level 1 backup on each day Monday through Saturday backs up all blocks changed since the Sunday backup.

Block Change Tracking

The block change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a block change tracking file. This file is a small binary file stored in the database area. RMAN tracks changed blocks as redo is generated.

If you enable block change tracking, then RMAN uses the change tracking file to identify changed blocks for an incremental backup, thus avoiding the need to scan every block in the datafile. RMAN only uses block change tracking when the incremental level is greater than 0 because a level 0 incremental backup includes all blocks.

Incremental Backup Algorithm

The following concepts are essential for understanding the algorithm that RMAN uses to make incremental backups:

  • Checkpoint SCN

    Every datafile has a checkpoint SCN, which you can view in V$DATAFILE.CHECKPOINT_CHANGE#. All changes with an SCN lower than this SCN are guaranteed to be in the file. When a level 0 incremental backup is restored, the restored datafile contains the checkpoint SCN that it had when the level 0 was created. When a level 1 incremental is applied to a file, the checkpoint SCN of the file is advanced to the checkpoint SCN that the file had when the incremental level 1 was created.

  • Incremental start SCN

    This SCN applies only to level 1 incremental backups. All blocks whose SCN is greater than or equal to the incremental start SCN are included in the backup. Blocks whose SCN is lower than the incremental start SCN are not included in the backup. The incremental start SCN is most often the checkpoint SCN of the parent of the level 1 backup.

  • Block SCN

    Every data block in a datafile records the SCN at which the most recent change was made to the block.

When RMAN makes an incremental backup of a file, RMAN reads the file, examines the SCN of every block, and backs up blocks whose SCN is greater than or equal to the incremental start SCN for this backup. If the backup is differential, then the incremental start SCN is the checkpoint SCN of the most recent level 1 backup. If the backup is cumulative, then the incremental start SCN is the checkpoint SCN of the most recent level 0 backup.

When block change tracking is enabled, RMAN uses bitmaps to avoid reading blocks that have not changed during the range from incremental start SCN to checkpoint SCN. Note that RMAN still examines every block that is read and uses the SCN in the block to decide which blocks to include in the backup.

One consequence of the incremental backup algorithm is that RMAN applies all blocks containing changed data during recovery, even if the change is to an object created with the NOLOGGING option. Thus, if you restore a backup made before NOLOGGING changes were made, then incremental backups are the only way to recover them.

See Also:

Oracle Database Concepts for more information about NOLOGGING mode

Recovery with Incremental Backups

During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. If it has a choice, then RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than applying redo.

RMAN does not need to restore a base incremental backup of a datafile to apply incremental backups to the datafile during recovery. For example, you can restore datafile image copies and recover them with incremental backups.

Backup Retention Policies

You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers a backup of datafiles or control files as an obsolete backup, that is, no longer needed for recovery, according to criteria specified in the CONFIGURE command. You can use the REPORT OBSOLETE command to view obsolete files and the DELETE OBSOLETE command to delete them.

As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention policy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy.

If a flash recovery area is configured, then the database automatically deletes files that are either obsolete or already backed up to tape when more recovery area space is needed for new files. The disk quota rules are distinct from the retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota.

A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered an expired backup only when RMAN performs a crosscheck and cannot find the file. In short, obsolete means a file is not needed, whereas expired means it is not found.

A retention policy applies only to full or level 0 datafile and control file backups. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backup sets, RMAN cannot delete the backup set until all datafile backups within the backup set are obsolete.

The retention policy does not directly affect archived redo logs and incremental level 1 backups. Rather, these files become obsolete when no full backups exist that need them. Besides affecting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained.


RMAN cannot implement an automatic retention policy if backups are deleted by non-RMAN techniques, for example, through the media manager's tape retention policy. The media manager should never expire a tape until all RMAN backups on that tape have been removed from the media manager's catalog.

There are two mutually exclusive options for implementing a retention policy: redundancy and recovery window.

Recovery Window

A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then RMAN retains full backups and required incremental backups and archived logs so that the database can be recovered up to 7 days in the past. You implement this retention policy as follows:


This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then there must always exist one backup of each datafile that satisfies the following condition:


All backups older than the most recent backup that satisfied this condition are obsolete.

Assume the following retention policy illustrated in Figure 7-4. The retention policy has the following aspects:

  • The recovery window is 7 days.

  • Database backups are scheduled every two weeks on these days:

    • January 1

    • January 15

    • January 29

    • February 12

  • The database runs in ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.

Figure 7-4 Recovery Window, Part 1

Description of Figure 7-4 follows
Description of "Figure 7-4 Recovery Window, Part 1"

As illustrated in Figure 7-4, the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 through 850. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.

Assume the same scenario a week later, as depicted in Figure 7-5.

Figure 7-5 Recovery Window, Part 2

Description of Figure 7-5 follows
Description of "Figure 7-5 Recovery Window, Part 2"

In this scenario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is not obsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because restoring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability to any point in the window, you must save the January 14 backup and all archived logs from sequence 500 to 1150.

Backup Redundancy

In some cases using a recovery window can complicate disk space planning because the number of backups that must be retained is not constant and depends on the backup schedule. In contrast, a redundancy-based retention policy specifies how many backups of each datafile must be retained. For example, you can configure a redundancy of 2 as follows:


The default retention policy is configured to REDUNDANCY 1.

Batch Deletes of Obsolete Backups

You can run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy. A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You can run DELETE OBSOLETE periodically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script.

You can also override the configured retention policy the configured retention policy by specifying the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands. Note that using DELETE OBSOLETE with a recovery window shorter than the configured recovery window effectively reduces the window of recoverability. For example, if the configured window is 14 days, but you execute DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS, then you will no longer be able to recover to a time between 7 and 14 days ago.

See Also:

Backup Retention Policy and Flash Recovery Area Deletion Rules

The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is considered OBSOLETE in the RMAN repository, it is because it is either not needed for recovery to a point within the recovery window, or it is redundant.

If you configure a flash recovery area, then the database uses an internal algorithm to select files in the flash recovery area that are no longer needed to meet the configured retention policy. These backups have status OBSOLETE and are eligible for deletion to satisfy the disk quota rules. The retention policy is never violated when determining which files to delete from the flash recovery area to satisfy the disk quota rules.

There is one important difference between the flash recovery area rules for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the current recovery window and so are not obsolete. If you back up these logs to tape, then the retention policy considers the disk logs as required, that is, not obsolete. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have been backed up to tape. The logs on disk do not have OBSOLETE status in the repository, but they are eligible for deletion by the flash recovery area.