The recommended maintenance strategy is to configure a fast 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 fast 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 fast recovery area may require occasional maintenance. For example, the fast recovery area may become full, in which case you can 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 accurate information.

RMAN provides multiple commands to maintain RMAN backups and repository records.

Following are the RMAN maintenance commands:

• 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.

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 data files, online redo log files, 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 too large because of the addition of new records, records can be reused if they are older than a threshold that 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 of age 14 days or older is a candidate for reuse. Information in an overwritten record is lost. The oldest record available for reuse is used first.

When the database must 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. 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

The best way to prevent the loss of RMAN metadata because of overwritten control file records is to use a recovery catalog.

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.

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. Oracle recommends 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. If 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 can use the DBID to recover the database.

RMAN uses certain rules to determine when files can be deleted from the fast recovery area.

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.

• 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.

  Consumers of logs can include RMAN, standby databases, and the Flashback Database feature.

• Foreign archived logs that have been mined by a LogMiner session on a logical standby database are eligible for deletion. Because it is generated from a different database than the current database, a foreign archived redo log has a different DBID than the current archived redo logs.

The safe and reliable way to control deletion of files from the fast recovery area is to configure your retention policy and archived log deletion policy. To increase the likelihood that files moved to tape are retained on disk, increase the fast recovery area quota.

You can use the V$RECOVERY_FILE_DEST and V$RECOVERY_AREA_USAGE views to determine whether you have allocated enough space for your fast recovery area.

SELECT * FROM V$RECOVERY_FILE_DEST;

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

SELECT * FROM V$RECOVERY_AREA_USAGE;

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

You cannot manage the flashback logs in the fast recovery area directly other than by setting the flashback retention target or using guaranteed restore points.

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

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

Use the ALTER SYSTEM command to change the location of the fast recovery area.

1. Start 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 fast recovery area files are 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 fast recovery area as they become eligible for deletion.

   If you must move the old files to the new fast recovery area, then see the Oracle Automatic Storage Management Administrator's Guide. 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 fast recovery area.

The ALTER SYSTEM command can be used to disable the fast recovery area.

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

As a rule, the fast recovery area is self-maintaining. When an instance crashes during the creation of a file in the fast recovery area, however, the database may leave the file in the fast recovery area.

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

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 fast recovery area, backup retention policy, and archived redo log deletion policy, then you do not need to perform crosschecks very often. If you delete files by means other than RMAN, then you must perform a crosscheck periodically to ensure that the repository data stays current.

RMAN provides multiple methods of changing the repository status of backups and copies.

Perform any of the following tasks to change the repository status of backups and copies:

• Making backups available or unavailable

  You can 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.

  Updating a Backup to Status AVAILABLE or UNAVAILABLE describes how to make backups available or unavailable.

• Including or exempting backups from the retention policy

  Archival backups can be created by using the KEEP clause to exempt backups from the configured retention policy. You can also change the status of an archival backup and subsequently include it in the configured retention policy.

  Changing the Status of an Archival Backup describes how to change the status of archival backups.

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.

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 views 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.

Use the RMAN DELETE command to delete backups and image copies.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. If necessary, allocate maintenance channels for the devices containing the backups to be deleted.

   As explained in Table 12-1, RMAN uses all configured channels to perform the deletion. If channels are 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.

You can use both the DELETE and BACKUP ... DELETE commands to delete specific backups and copies.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. If necessary, allocate maintenance channels for the devices containing the backups to be deleted.

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

3. Delete the specified backups and copies.

   The following examples show many of the common ways to specify backups and archived logs to delete with the DELETE command:

   • Deleting backups using primary keys from LIST output:

     DELETE BACKUPPIECE 101;
     

   • Deleting backups by file name on disk:

     DELETE CONTROLFILECOPY '/tmp/control01.ctl';
     

   • Deleting archived redo logs:

     DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 300;
     

   • Deleting backups based on tags:

     DELETE BACKUP TAG 'before_upgrade';
     

   • Deleting backups based on the objects backed up and the media or disk location where the backup is stored:

     DELETE BACKUP OF TABLESPACE users DEVICE TYPE sbt; # delete only from tape
     DELETE COPY OF CONTROLFILE LIKE '/tmp/%';
     

   • Deleting archived redo logs from disk based on whether they are backed up on tape:

     DELETE ARCHIVELOG ALL 
        BACKED UP 3 TIMES TO sbt;

   • Deleting backup sets that were backed up twice to tape:

     DELETE BACKUPSET DEVICE TYPE disk BACKED UP 2 TIMES TO sbt;

   • Deleting backups of the target database that were backed up once to tape:

     DELETE BACKUP OF DATABASE DEVICE TYPE disk BACKED UP 1 TIMES TO sbt;

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.

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;

The RMAN DELETE command supports an OBSOLETE option, which deletes backups that are no longer needed to satisfy specified recoverability requirements.

DELETE OBSOLETE;