11 Maintaining RMAN Backups and Repository Records

Purpose of Backup and Repository Maintenance

The recommended maintenance strategy is to configure a flash recovery area, a backup retention policy, and an archived redo log deletion policy. In this case, the database automatically maintains and deletes backups and archived redo logs as needed. However, manual maintenance of database backups and archived redo logs is sometimes necessary.

Managing RMAN backups involves the following related tasks:

• Managing the database backups that are stored on disk or tape

• Managing the records of those backups in the RMAN repository

An important part of RMAN maintenance is deleting backups that are no longer needed. If you configure a flash recovery area, then the database automatically deletes unneeded files in this area automatically; even so, you may want to delete backups and copies from tape. You may even need to delete an entire database. You can use an RMAN command to perform these tasks.

The flash recovery area may require occasional maintenance. For example, the flash recovery area may become full, in which case you may need to add space to it. Alternatively, you may want to change the location of the recovery area.

It is possible for the RMAN repository to fail to reflect the true state of files on disk or tape. For example, a user may delete a backup from disk with an operating system utility. In this case, the RMAN repository shows that the file exists when it does not. In a similar situation, a tape containing RMAN backups may be corrupted. You can use RMAN maintenance commands to update the repository with true information.

Basic Concepts of Backup and Repository Maintenance

The RMAN maintenance commands are summarized as follows:

• The CATALOG command enables you to add records about RMAN and user-managed backups that are currently not recorded in the RMAN repository, or to remove records for backups that are recorded.

• The CHANGE command enables you to update the status of records in the RMAN repository.

• The CROSSCHECK command enables you to synchronize the logical backup records with the physical reality of files in backup storage.

• The DELETE command enables you to delete backups from the operating system.

About Control File Records

The control file contains two types of records: circular reuse records and noncircular reuse records.

Circular reuse records contain noncritical information that is eligible to be overwritten if needed. These records contain information that is continually generated by the database. When all available record slots are full, the database either expands the control file to make room for a new record or overwrites the oldest record. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in days of a record before it can be reused.

Noncircular reuse records contain critical information that does not change often and cannot be overwritten. Some examples of information in noncircular reuse records include datafiles, online redo logs, and redo threads.

As you make backups of a target database, the database records these backups in the control file. To prevent the control file from growing without bound to hold RMAN repository data, records can be reused if they are older than a threshold you specify. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum age in days of a record before it can be overwritten:

CONTROL_FILE_RECORD_KEEP_TIME = integer

For example, if the parameter value is 14, then any record aged 14 days and older is a candidate for reuse. Information in an overwritten record is lost. The oldest record available for reuse will be used first.

When the database needs to add new RMAN repository records to the control file, but no record is older than the threshold, the database attempts to expand the size of the control file. If the underlying operating system prevents the expansion of the control file (due to a disk full condition, for instance), then the database overwrites the oldest record in the control file.

The database records the overwrite in the alert log located in the Automatic Diagnostic Repository (ADR). For each record that it overwrites, the database records an entry in the alert log similar to the following:

kccwnc: following control file record written over:  
RECID #72 Recno 72 Record timestamp  
07/28/06 22:15:21  
Thread=1 Seq#=3460  
Backup set key: stamp=372031415, count=17  
Low scn: 0x0000.3af33f36  
07/27/06 21:00:08  
Next scn: 0x0000.3af3871b  
07/27/06 23:23:54
Resetlogs scn and time  
scn: 0x0000.00000001

kccwnc: trying to expand control file section nnnn for Oracle Managed Files

WARNING: Oracle Managed File filename is unknown to control file. This is the result of limitation in control file size that could not keep all recovery area files. 

Preventing the Loss of Control File Records

The best way to prevent the loss of RMAN metadata because of overwritten control file records is to use a recovery catalog. If you cannot use a recovery catalog, then you can take the following measures:

• Set the CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file that you need to keep. For example, if you back up the whole database once a week, then you need to keep every backup for at least seven days. Set CONTROL_FILE_RECORD_KEEP_TIME to a value such as 10 or 14. The default value of CONTROL_FILE_RECORD_KEEP_TIME is 7 days.

  Caution:

  Regardless of whether you use a recovery catalog, never use RMAN when CONTROL_FILE_RECORD_KEEP_TIME is set to 0. If you do, then you may lose backup records.

• Store the control file in a file system rather than raw device so that it can expand.

• Monitor the alert log to ensure that Oracle is not overwriting control file records. The alert log is located in the Automatic Diagnostic Repository (ADR).

If you use a flash recovery area, then follow these guidelines to avoid a situation in which the control file cannot hold a record of all flash recovery area files needed to satisfy the backup retention policy:

• If the block size of the control file is not already at its maximum, then use a larger block size, preferably 32 KB.

  To achieve this aim, you must set the SYSTEM tablespace block size to be greater than or equal to the control file block size, and re-create the control file after changing DB_BLOCK_SIZE. Note that the files in the flash recovery area will be recataloged, but the records for files on tape will be lost.

• Make the files in the flash recovery area eligible for deletion by backing them up to tertiary storage such as tape.

  For example, you can use BACKUP RECOVERY AREA to specifically back up files in the flash recovery area to a media manager.

• If the backup retention policy is keeping backups and archived logs longer than your business requirements, then you can make more files in the flash recovery area eligible for deletion by changing the retention policy to a shorter recovery window or lower degree of redundancy.

Protecting the Control File

If you are not using a recovery catalog to store RMAN metadata, then it is doubly important that you protect each target database control file. You can use the following strategy to protect the control file.

To protect the control file:

1. Create redundant copies of control files through multiplexing or operating system mirroring.

   In this way, the database can survive the loss of a subset of the control files without requiring you to restore a control file from backup. It is recommended that you use a minimum of two multiplexed or mirrored control files on separate disks.

2. Configure the control file autobackup feature.

   In this case, RMAN automatically backs up the control file when you run certain RMAN commands. As long as a control file autobackup is available, RMAN can restore the server parameter and backup control file, and mount the database. After the control file is mounted, you can restore the remainder of the database.

3. Keep a record of the database DBID.

   If you lose the control files, then you may need the DBID to recover the database.

Deletion Rules for the Flash Recovery Area

"Overview of the Flash Recovery Area" explains the contents of the flash recovery area and the difference between permanent and transient files. Review this section before proceeding. The following rules govern when files become eligible for deletion from the recovery area:

• Permanent files are never eligible for deletion.

• Files that are obsolete under the retention policy are eligible for deletion.

  "Configuring the Backup Retention Policy" explains how to configure the retention policy.

• Transient files that have been copied to tape are eligible for deletion.

• Archived redo logs are not eligible for deletion until all the consumers of the logs have satisfied their requirements.

  "Configuring an Archived Redo Log Deletion Policy" explains how to configure an archived redo log deletion policy that determines when logs are eligible to be deleted. Consumers of logs can include RMAN, standby databases, Oracle Streams databases, and the Flashback Database feature. See Oracle Data Guard Concepts and Administration to learn about archived redo log management in a Data Guard environment.

• Foreign archived logs that have been mined by a LogMiner session on a logical standby database are eligible for deletion. Unlike an ordinary archived redo log, a foreign archived redo log has a different DBID.

The safe and reliable way to control deletion of files from the flash recovery area is to configure your retention policy ("Configuring the Backup Retention Policy") and archived log deletion policy ("Configuring an Archived Redo Log Deletion Policy"). To increase the likelihood that files moved to tape are retained on disk, increase the flash recovery area quota.

Monitoring Flash Recovery Area Space Usage

You can use the V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA_USAGE views to determine whether you have allocated enough space for your flash recovery area. Query the V$RECOVERY_FILE_DEST view to find out the current location, disk quota, space in use, space reclaimable by deleting files, and total number of files in the flash recovery area. For example, enter the query shown in Example 11-1 (sample output included). Note that the space columns specify the amount in bytes.

SELECT * FROM V$RECOVERY_FILE_DEST;

NAME            SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
--------------  ----------- ---------- ----------------- ---------------
/mydisk/rcva     5368709120 109240320             256000              28

Query the V$FLASH_RECOVERY_AREA_USAGE view to find out the percentage of the total disk quota used by different types of files. Also, you can determine how much space for each type of file can be reclaimed by deleting files that are obsolete, redundant, or already backed up to tape. For example, enter the following query (sample output included):

SELECT * FROM   V$FLASH_RECOVERY_AREA_USAGE;

FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE                   0                         0               0
ONLINELOG                     2                         0              22
ARCHIVELOG                 4.05                      2.01              31
BACKUPPIECE                3.94                      3.86               8
IMAGECOPY                 15.64                     10.43              66
FLASHBACKLOG                .08                         0               1

When guaranteed restore points are defined on your database, you should monitor the amount of space used in your flash recovery area for files required to meet the guarantee. Use the query for viewing guaranteed restore points in "Listing Restore Points" and refer to the STORAGE_SIZE column to determine the space required for files related to each guaranteed restore point.

Managing Space For Flashback Logs in the Flash Recovery Area

"Configuring Oracle Flashback Database and Restore Points" explains the rules for flashback log deletion. You cannot manage the flashback logs in the flash recovery area directly other than by setting the flashback retention target or using guaranteed restore points. Nevertheless, you can manage flash recovery area space as a whole in order to maximize space available for retention of flashback logs. In this way you increase the likelihood of achieving the flashback target.

To make space for flashback logs, back up the other contents of your flash recovery area to tape with commands such as BACKUP RECOVERY AREA, BACKUP BACKUPSET, and so on. Oracle Database automatically removes obsolete files from the flash recovery area. If offloading backups to tape still does not create enough space to satisfy the backup retention policy and flashback retention target, then allocate more space in the flash recovery area.

Responding to a Full Flash Recovery Area

If the RMAN retention policy requires keeping a set of backups larger than the flash recovery area disk quota, or if the retention policy is set to NONE, then the flash recovery area can fill completely with no reclaimable space.

The database issues a warning alert when reclaimable space is less than 15% and a critical alert when reclaimable space is less than 3%. To warn the DBA of this condition, an entry is added to the alert log and to the DBA_OUTSTANDING_ALERTS table (used by Enterprise Manager). Nevertheless, the database continues to consume space in the flash recovery area until there is no reclaimable space left.

When the recovery area is completely full, the error you will receive is as follows, where nnnnn is the number of bytes required and mmmm is the disk quota:

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit

You have a number of choices on how to resolve a full flash recovery area when no files are eligible for deletion:

• Make more disk space available and increase DB_RECOVERY_FILE_DEST_SIZE to reflect the additional space.

• Move backups from the flash recovery area to tertiary storage such as tape.

  One convenient way to back up all of your recovery area files to tape at once is the BACKUP RECOVERY AREA command. After you transfer backups from the recovery area to tape, you can delete files from the flash recovery area (see "Deleting RMAN Backups and Archived Redo Logs"). Note that flashback logs cannot be backed up outside the recovery area and so are not backed up by BACKUP RECOVERY AREA.

• Run DELETE for any files that have been removed with an operating system utility.

  If you use host operating system commands to delete files, then the database will not be aware of the resulting free space. You can run the RMAN CROSSCHECK command to have RMAN re-check the contents of the flash recovery area and identify expired files, and then use the DELETE EXPIRED command to every expired backup from the RMAN repository.

• Make sure that your guaranteed restore points are necessary. If not, delete them as described in "Dropping Restore Points".

  Flashback logs that are not needed for a guaranteed restore point are deleted automatically to gain space for other files in the flash recovery area. A guaranteed restore point forces the retention of flashback logs required to perform Flashback Database to the restore point SCN.

• Review your backup retention policy and, if using Data Guard, your archived redo log deletion policy.

Dropping Restore Points

When you are satisfied that you do not need an existing restore point, or when you want to create a new restore point with the name of an existing restore point, you can drop the restore point, using the DROP RESTORE POINT SQL statement. For example:

DROP RESTORE POINT before_app_upgrade;

The same statement is used to drop both normal and guaranteed restore points.

Normal restore points eventually age out of the control file, even if not explicitly dropped. The rules governing retention of restore points in the control file are:

• The most recent 2048 restore points are always kept in the control file, regardless of their age.

• Any restore point more recent than the value of CONTROL_FILE_RECORD_KEEP_TIME is retained, regardless of how many restore points are defined.

Normal restore points that do not meet either of the preceding conditions may age out of the control file. Guaranteed restore points never age out of the control file. They remain until they are explicitly dropped.

Changing the Flash Recovery Area to a New Location

If you need to move the flash recovery area of your database to a new location, then follow this procedure:

1. Start a SQL*Plus on the target database and change the DB_RECOVERY_FILE_DEST initialization parameter. For example, enter the following command to set the destination to the ASM disk group disk1:

   ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
   

   After you change this parameter, all new flash recovery area files will be created in the new location.

2. Either leave or move the permanent files, flashback logs, and transient files in the old flash recovery location.

   If you leave the existing files in the flash recovery, then the database deletes the transient files from the old flash recovery area as they become eligible for deletion.

   If you need to move the old files to the new flash recovery area, then see Chapter 26, "Performing ASM Data Migration". The procedure for moving database files into and out of an ASM disk group with RMAN works when moving files into and out of a flash recovery area.

Disabling the Flash Recovery Area

To disable the flash recovery area, set the DB_RECOVERY_FILE_DEST initialization parameter to a null string. For example, use the following SQL statement to change the parameter on a running database:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';

The database will no longer provide the space management features of the flash recovery area for the files stored in the old DB_RECOVERY_FILE_DEST location. The files will still be known to the RMAN repository, however, and available for backup and restore activities.

Responding to an Instance Crash During File Creation

As a rule, the flash recovery area is self-maintaining. When an instance crashes during the creation of a file in the flash recovery area, however, the database may leave the file in the flash recovery area. When this situation occurs, you will see the following error in the alert log, where location is the location of the flash recovery area:

ORA-19816: WARNING: Files may exist in location that are not known to database.

In such a situation, use the RMAN command CATALOG RECOVERY AREA to recatalog any such files. If the file header of the file in question is corrupted, then delete the file manually with an operating system utility.

Monitoring Flashback Database Performance Impact

The Automatic Workload Repository (AWR) automates database statistics gathering by collecting, processing, and maintaining performance statistics for the purpose of database problem detection and self-tuning. The best way to monitor system usage caused by flashback logging is through AWR snapshots. For example, if flashback buf free by RVWR is the top wait event, then you know that Oracle Database cannot write flashback logs very quickly. In such a case, you may want to tune the file system and storage used by the flash recovery area, possibly using one of the techniques described in "Configuring the Environment for Optimal Flashback Database Performance".

The V$FLASHBACK_DATABASE_STAT view shows the bytes of flashback data logged by the database. Each row in the view shows the statistics accumulated (typically over the course of an hour). The FLASHBACK_DATA and REDO_DATA columns describe bytes of flashback data and redo data written respectively during the time interval, while the DB_DATA column describe bytes of data blocks read and written. Note that FLASHBACK_DATA and REDO_DATA correspond to sequential writes, while DB_DATA corresponds to random reads and writes.

Because of the difference between sequential I/O and random I/O, a better indication of I/O overhead is the number of I/O operations issued for flashback logs. The V$SYSSTAT statistics shown in Table 11-1 can tell you the number of I/O operations your instance has issued for various purposes.

Flashback Writer (RVWR) Behavior With I/O Errors

When flashback is enabled or when there are guaranteed restore points, the background process RVWR writes flashback data to flashback database logs in the flash recovery area. If RVWR encounters an I/O error, the following behavior is expected:

• If there are any guaranteed restore points defined, then the instance will fail when RVWR encounters I/O errors.

• If no guaranteed restore points are defined, then the instance will not fail when RVWR encounters I/O errors. Note the following cases:

  • On a primary database, Oracle Database automatically disables Flashback Database while the database is open. All existing transactions and queries will proceed unaffected. This behavior is expected for both single-instance and Oracle RAC databases.

  • On a physical or logical standby, RVWR will appear to be hung, retrying the I/O periodically. This may eventually hang the logical standby or the managed recovery of the physical standby. (Oracle Database does not cause the standby instance to fail because it does not want to cause the primary database to fail in turn in max protection mode.) To resolve the hang, you can either issue SHUTDOWN ABORT or ALTER DATABASE FLASHBACK OFF.

Crosschecking the RMAN Repository

To ensure that data about backups in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog, perform a crosscheck. The CROSSCHECK command operates only on files that are currently recorded in the RMAN repository.

If you use a flash recovery area, backup retention policy, and archived redo log deletion policy, then you should not need to perform crosschecks very often. If you delete files by means other than RMAN, then you should perform a crosscheck periodically to make sure that the repository data stays current.

About RMAN Crosschecks

Crosschecks update outdated RMAN repository information about backups whose repository records do not match their physical status. For example, if a user removes archived logs from disk with an operating system command, the repository still indicates that the logs are on disk, when in fact they are not.

Figure 11-1 illustrates a crosscheck of a media manager. RMAN queries the RMAN repository for the names and locations of the four backup pieces to be checked. RMAN sends this information to the target database server, which queries the media management software about the backups. The media management software then checks its media catalog and reports back to the server that backup set 3 is missing. RMAN updates the status of backup set 3 to EXPIRED in the repository. The record for backup set 3 will now be deleted if you run DELETE EXPIRED.

Figure 11-1 Crosschecking a Media Manager

Description of "Figure 11-1 Crosschecking a Media Manager"

Crosschecks are useful because they can do the following:

• Update outdated information about backups that disappeared from disk or tape or became corrupted

• Update the repository if you delete archived redo logs or other files with operating system commands

Use the crosscheck feature to check the status of a backup on disk or tape. If the backup is on disk, then CROSSCHECK checks whether the header of the file is valid. If a backup is on tape, then the command checks that the backups exist in the media management software catalog.

Backup pieces and image copies can have the status AVAILABLE, EXPIRED, or UNAVAILABLE. You can view the status of backups by running the RMAN LIST command or by querying V$BACKUP_FILES or recovery catalog views such as RC_DATAFILE_COPY or RC_ARCHIVED_LOG. A crosscheck updates the RMAN repository so that all of these techniques provide accurate information. RMAN updates each backup in the RMAN to status EXPIRED if the backup is no longer available. If a new crosscheck determines that an expired backup is available again, then RMAN updates its status to AVAILABLE.

Note:

The CROSSCHECK command does not delete operating system files or remove repository records. You must use the DELETE command for these operations.

You can issue the DELETE EXPIRED command to delete all expired backups. RMAN removes the record for the expired file from the repository. If for some reason the file still exists on the media, then RMAN issues warnings and lists the mismatched objects that cannot be deleted.

See Also:

• Oracle Database Backup and Recovery Reference for CROSSCHECK syntax and a description of the possible status values

• Oracle Database Backup and Recovery Reference for DELETE syntax

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE sbt;

CROSSCHECK BACKUP;
CROSSCHECK COPY;

allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=12 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp=408384484
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/oracle/dbs/c-674966176-20000915-01 recid=37 stamp=408384496
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=12c5erb2_1_1 recid=32 stamp=408382820
.
.
.

RUN
{
  ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
  CROSSCHECK BACKUP;
  CROSSCHECK COPY;
}

Changing the Repository Status of Backups and Copies

This section explains how to change the repository records for backups and copies. You may need to change the status of a backup if it becomes temporarily available or unavailable. For example, if a mounted disk undergoes maintenance, then you can update the records for backups on the disk to status UNAVAILABLE.

Adding Records to the RMAN Repository

You can use the CATALOG command to make RMAN aware of the existence of archived logs not recorded in the repository or copies of database files that are created through means other than RMAN. This section contains the following topics:

• About Cataloging Operations

• Cataloging User-Managed Datafile Copies

• Cataloging Backup Pieces

• Cataloging All Files in a Disk Location

Removing Records from the RMAN Repository

This section explains how to remove records for files from the RMAN repository.

Overview of RMAN Deletion

Every RMAN backup produces a corresponding record in the RMAN repository. This record is stored in the control file. If a recovery catalog is used, then the record can also be found in the recovery catalog after the recovery catalog is resynchronized from the control file. For example, if you generate a full database backup set, then you can view the record for this backup set in V$BACKUP_SET. If you use a recovery catalog, then you can also access the record in the RC_BACKUP_SET catalog view.

The V$ control file views and recovery catalog tables differ in the way that they store information, and this affects how RMAN handles repository records. The recovery catalog RMAN repository is stored in actual database tables, while the control file version of the repository is stored in an internal structure in the control file.

When you use an RMAN command to delete a backup or archived redo log file, RMAN does the following:

• Removes the physical file from the operating system (if the file is still present)

• Updates the file records in the control file to status DELETED

• Removes the file records from the recovery catalog tables (if RMAN is connected to a recovery catalog)

Because of the way that control file data is stored, RMAN cannot remove the record from the control file, only update it to DELETED status. Because the recovery catalog tables are ordinary database tables, however, RMAN deletes rows from them in the same way that rows are deleted from any table.

DELETE NOPROMPT ARCHIVELOG ALL;

Deleting All Backups and Copies

In some circumstances, you may need to delete all backup sets, proxy copies, and image copies associated with a database. For example, you no longer need a database and want to remove all related files from the system. Note that an image copy is a file generated with BACKUP AS COPY, a log archived by the database, or a file cataloged with the CATALOG command.

To delete all backups and copies:

1. Start an RMAN session on the target database, which must be mounted or open.

2. If necessary, allocate maintenance channels for the devices containing the backups to be deleted.

   As explained in Table 11-2, RMAN uses all configured channels to perform the deletion. If channels are already configured, then you do not need to manually allocate maintenance channels.

3. Crosscheck the backups and copies to ensure that the logical records are synchronized with the physical media.

   CROSSCHECK BACKUP;
   CROSSCHECK COPY;
   

4. Delete the backups and copies.

   For example, enter the following commands and then enter YES when prompted:

   DELETE BACKUP;
   DELETE COPY;
   

   If disk and tape channels are configured, then RMAN uses both the configured SBT channel and the preconfigured disk channel when deleting. RMAN prompts you for confirmation before deleting any files.

Deleting Specified Backups and Copies

You can use both the DELETE and BACKUP ... DELETE commands to delete specific backups and copies. The BACKUP ... DELETE command backs up the files first, typically to tape, and then deletes the input files afterward.

Deleting Expired RMAN Backups and Copies

If you run CROSSCHECK, and if RMAN cannot locate the files, then it updates their records in the RMAN repository to EXPIRED status. You can then use the DELETE EXPIRED command to remove records of expired backups and copies from the RMAN repository.

The DELETE EXPIRED command issues warnings if any files marked as EXPIRED actually exist. In rare cases, the repository can mark a file as EXPIRED even though it exists. For example, a directory containing a file is corrupted at the time of the crosscheck, but is later repaired, or the media manager was not configured properly and reported some backups as not existing when they really existed.

To delete expired repository records:

1. If you have not performed a crosscheck recently, then issue a CROSSCHECK command. For example, issue:

   CROSSCHECK BACKUP;
   

2. Delete the expired backups. For example, issue:

   DELETE EXPIRED BACKUP;
   

Deleting Obsolete RMAN Backups Based on Retention Policies

The RMAN DELETE command supports an OBSOLETE option, which deletes backups that are no longer needed to satisfy specified recoverability requirements. You can delete files obsolete according to the configured default retention policy, or another retention policy that you specify as an option to the DELETE OBSOLETE command. As with other forms of the DELETE command, the files deleted are removed from backup media, deleted from the recovery catalog, and marked as DELETED in the control file.

If you specify the DELETE OBSOLETE command with no arguments, then RMAN deletes all obsolete backups defined by the configured retention policy. For example:

DELETE OBSOLETE;