6
Recovery Manager Maintenance Tasks

This chapter describes how to manage the RMAN repository and some maintenance tasks related to the flash recovery area.

This chapter contains these topics:

• Managing the RMAN Repository Without a Recovery Catalog
• Crosschecking Backups
• Deleting Backups
• Deleting a Database with RMAN
• Crosschecking and Deleting on Multiple RMAN Channels
• Changing the Status of a Backup Record
• Cataloging Archived Logs and User-Managed Copies
• Uncataloging RMAN Records
• Flash Recovery Area Maintenance

  See Also: Oracle Database Backup and Recovery Advanced User's Guide for more in-depth information about managing the RMAN repository when using a recovery catalog

Managing the RMAN Repository Without a Recovery Catalog

The authoritative RMAN repository is always stored in the database control file. The repository contents can also be stored in a recovery catalog database, as an adjunct to the information stored in the control file.

While RMAN is designed to work without a recovery catalog, if you choose not to use a recovery catalog, you must perform some additional administrative tasks.

Backing Up and Restoring the Control File

If you are not using a recovery catalog, the control file is the sole storage for the RMAN repository, so it is doubly important that you protect it. Maintain alternate control files through multiplexing or operating system mirroring, and back up the control file frequently.

Configure CONTROLFILE AUTOBACKUP to ON to ensure extra protection for your control file.

So long as a control file autobackup is available, RMAN can restore the SPFILE and backup control file, and mount the database. After the control file is mounted, you can restore the remainder of the database.

Note that, if you restore a control file from autobackup, any persistent settings you set with the CONFIGURE command will revert to the values they had at the time of the control file autobackup. You should review the settings with the SHOW ALL after restoring the control file.

Monitoring the Overwriting of Control File Records

When you do not use a recovery catalog, the control file is the sole source of information about RMAN backups. As you make backups, Oracle records these backups in the control file. To prevent the control file from growing without bound to hold RMAN repository data, records can be re-used if they are older than a threshhold 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 re-use will be used first.

When Oracle needs to add new RMAN repository records to the control file, but no record is older than the threshhold, Oracle 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), Oracle overwrites the oldest record in the control file and logs this action in the alert log.

The default value of CONTROL_FILE_RECORD_KEEP_TIME is 7 days. If you are not using a recovery catalog, then 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 database once a week, then you need to keep every backup at least a week. Set CONTROL_FILE_RECORD_KEEP_TIME to a value such as 10 or 14.

Managing the Overwriting of Control File Records: Scenario

Assume the following scenario:

• You do not use a recovery catalog.
• CONTROL_FILE_RECORD_KEEP_TIME is set to 14.
• All records currently in the control file are between 1 and 13 days old.
• The control file is at the maximum size permitted by the operating system.

You make a backup of the database. Because Oracle cannot expand the control file beyond the operating system file size limit, it begins overwriting records in the control file, starting with those records aged 13 days. For each record that it overwrites, it records an entry in the alert.log similar to the one shown here:

kccwnc: following controlfile record written over:  
RECID #72 Recno 72 Record timestamp  
07/28/00 22:15:21  
Thread=1 Seq#=3460  
Backup set key: stamp=372031415, count=17  
Low scn: 0x0000.3af33f36  
07/27/00 21:00:08  
Next scn: 0x0000.3af3871b  
07/27/00 23:23:54  
Resetlogs scn and time  
scn: 0x0000.00000001  
08/05/99 10:46:44  
Block count=102400 Blocksize=512

To guard against this type of scenario, use a recovery catalog. If you cannot use a recovery catalog, then do the following if possible:

• Store the control file in a file system rather than raw disk, so that it can expand as needed.
• Monitor the alert.log to make sure that Oracle is not overwriting control file records.

  See Also: Oracle Database Backup and Recovery Advanced User's Guide for a conceptual overview of control file records and how they are re-used

Interaction of Flash Recovery Area and CONTROL_FILE_RECORD_KEEP_TIME

Whe a control file record containing information about a file created in the flash recovery area is about to be reused (because the record is older than CONTROL_FILE_RECORD_KEEP_TIME), if the file is eligible for deletion then the database will attempt to delete the file from the flash recovery area. Otherwise, Oracle will expand the size of the control file section containing the record for this file, logging the expansion in the alert log with a message like this example:

kccwnc: tring to expand controlfile section nnnn for Oracle Managed Files

where nnnn is the record type number.

If Oracle is unable to expand the control file section, because the control file is at the maximum size supported under the host operating system, you will see this warning in the alert log:

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

This means that the control file cannot hold all flash recovery area files needed to satisfy the configured retention policy.

There are several ways to avoid or alleviate this problem:

• Use a control file of larger block size, preferably one with 32K block size. To achieve this, you must set the SYSTEM tablespace block size to be greater than or equal to the control file block size, and you need to re-create the control file after changing DB_BLOCK_SIZE.
• Make the files in the flash recovery area eligible for deletion, by backing them up to tertiary storage such as tape with the RMAN command BACKUP RECOVERY AREA, or by changing the retention policy to a shorter recovery window or lower degree of redundancy.

Maintaining the RMAN Repository in the Control File

RMAN provides several commands that enable you to check and delete records of backups as well as physically remove backups.

Crosschecking Backups

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 recorded in the recovery catalog or the control file.

This section contains these topics:

• About RMAN Crosschecks
• Crosschecking Specific Backup Sets and Copies
• Crosschecking Backups of Specific Database Files

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.

If the backup is on disk, then the CROSSCHECK command determines whether the header of the file is valid. If the backup is on tape, then the command simply checks that the backup exists. The possible status values for backups are AVAILABLE, UNAVAILABLE, and EXPIRED. View the status of backups in one of the following locations:

• The LIST command output
• V$BACKUP_FILES
• Various recovery catalog views such as RC_DATAFILE_COPY, RC_ARCHIVED_LOG, and so forth

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

  See Also: "Deleting Backups" to learn how to delete files and update repository records Oracle Database Recovery Manager Reference for CROSSCHECK command syntax and a description of the repository status values

Crosschecking Specific Backup Sets and Copies

You can use the LIST command to report your backups and then use the CROSSCHECK command to check that these files still exist. The DELETE EXPIRED command deletes repository records for backups that fail the crosscheck.

To crosscheck specified backups:

1. Identify the desired backups that you want to check by issuing a LIST command. For example, issue:

   LIST BACKUP;  # lists all backup sets, proxy copies, and image copies
   
   

2. Check whether the specified backups. For example, enter:

   CROSSCHECK BACKUP;  # checks backup sets, proxy copies, and image copies
   CROSSCHECK COPY OF DATABASE;
   CROSSCHECK BACKUPSET 1338, 1339, 1340;
   CROSSCHECK BACKUPPIECE TAG = 'nightly_backup';
   CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl';
   CROSSCHECK DATAFILECOPY 113, 114, 115;
   CROSSCHECK PROXY 789;
   
   

   If the backup is no longer available, then RMAN marks it as EXPIRED. If it was EXPIRED and is now available, then RMAN marks it AVAILABLE.

Crosschecking Backups of Specific Database Files

Use the LIST command to display backups, then use the CROSSCHECK command to check whether these backups exist.

To crosscheck backups of specified files:

Check for the backups of the specified database, tablespace, datafile, control file, or archived redo log. Limit the crosscheck according to the time sequence. For example, check all backups of datafile ora_home/oradata/trgt/system01.dbf over the last six months, as well as all archived logs and server parameter files:

# these CROSSCHECK commands use configured channels, which means that they
# always check the disk device. If you configured an sbt channel, then RMAN 
# checks the sbt device, too
CROSSCHECK BACKUP OF DATAFILE "ora_home/oradata/trgt/system01.dbf" 
  COMPLETED AFTER 'SYSDATE-180';
CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE;

Deleting Backups

You can use RMAN to delete backups (backup sets and disk copies of datafiles and archived logs). RMAN deletes the specified files and removes their repository records.

This section contains these topics:

• Deleting Specified Backups
• Deleting Expired Backups
• Deleting Obsolete Backups

  Note: Backups with DELETED status do not appear in the LIST command output. Query the V$ control file views instead.

  See Also: Oracle Database Recovery Manager Reference for DELETE syntax Oracle Database Recovery Manager Reference for descriptions of the recovery catalog views

Deleting Specified Backups

In general, use the DELETE command to remove backups that you no do not want to retain. This command removes the physical files, deletes the catalog records (if you use a catalog), and updates the records in the control file to status DELETED.

To delete backups and remove their repository records:

1. Run the LIST output to obtain primary keys of backups. For example:

   LIST BACKUP OF DATABASE ARCHIVELOG ALL; # lists backups of db files and logs
   LIST COPY; # lists only image copies
   LIST BACKUP; # lists everything
   
   

2. Run the DELETE command to eliminate the specified physical files and their repository records. For example:

   DELETE BACKUPPIECE 101;
   DELETE CONTROLFILECOPY '/tmp/control01.ctl';
   DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 300;
   
   

3. You can also delete files with DELETE BACKUP (which deletes backup sets, proxy copies, and image copies), DELETE COPY (which deletes only image copies), or DELETE ARCHIVELOG as in these examples:

   DELETE BACKUP; # deletes all backups on disk and tape
   DELETE BACKUP OF TABLESPACE users DEVICE TYPE sbt; # delete only from tape
   DELETE COPY OF CONTROLFILE LIKE '/tmp/%';  # LIKE specifies name of the copy
   DELETE NOPROMPT ARCHIVELOG ALL 
      BACKED UP 3 TIMES TO sbt; # backs up only if already backed up 3X to tape
   
   

   If you run RMAN interactively, then RMAN asks for confirmation before deleting any files. You can suppress these confirmations by using the NOPROMPT keyword:

   DELETE NOPROMPT ARCHIVELOG ALL 
      BACKED UP 3 TIMES TO sbt; # backs up only if already backed up 3X to tape
   

Deleting Expired Backups

Use the CROSSCHECK command to determine whether backups recorded in the repository still exist on disk or tape. If RMAN cannot locate the backups, then it updates their records to EXPIRED status. You can then use the DELETE EXPIRED command to remove expired records. If the expired files still exist, then the DELETE EXPIRED command terminates with an error.

To delete expired repository records:

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

   CROSSCHECK BACKUP; # checks backup sets and copies on configured channels
   
   

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

   DELETE EXPIRED BACKUP;
   

Deleting Obsolete Backups

Use the DELETE OBSOLETE command to remove backups that are obsolete, that is, eligible for deletion. You can determine what qualifies a backup for obsolete status in these ways:

• By configuring a retention policy with the CONFIGURE command
• By using the options on the DELETE OBSOLETE command

The DELETE OBSOLETE command removes both the physical files, deletes the recovery catalog records (if you use a catalog), and updates the records in the target control file to status DELETED.

Deleting Backups Rendered Obsolete by the Retention Policy

If you specify the DELETE OBSOLETE command with no other operands, then RMAN deletes all obsolete backups defined by the retention policy.

To delete backups made obsolete by the retention policy:

Issue a DELETE OBSOLETE command without any options to delete the objects defined as obsolete by the retention policy, for example:

DELETE OBSOLETE;

If you run RMAN interactively, then RMAN asks for confirmation before deleting any files. If you specify NOPROMPT, then RMAN does not ask for confirmation.

Deleting Backups Defined as Obsolete with the DELETE Command

You can run the DELETE OBSOLETE REDUNDANCY or DELETE OBSOLETE RECOVERY WINDOW commands to delete obsolete backups. The redundancy or recovery window setting on the DELETE command overrides setting on the CONFIGURE RETENTION POLICY command.

To specify which backups are obsolete and should be deleted:

Run a DELETE OBSOLETE command with the REDUNDANCY or RECOVERY WINDOW options. These options define what is obsolete during the delete job. For example, enter:

DELETE OBSOLETE REDUNDANCY = 3;
DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS;

Forcing the Deletion of Backups

It is possible for the RMAN repository to indicate that an object has one status while the actual status of the object on the media is different. For example, the RMAN repository says that a backup set is AVAILABLE when it is in fact missing from the media management catalog. If you attempt to delete the object, then you receive a warning such as the following:

RMAN-06207: WARNING: 1 objects could not be deleted for DISK channel(s) due
RMAN-06208:          to mismatched status.  Use CROSSCHECK command to fix status
List of Mismatched objects
==========================
  Object Type   Filename/Handle
--------------- ---------------------------------------------------
Backup Piece    0id270ud_1_1

You can force RMAN to delete any object and update its status in the RMAN repository by specifying the FORCE keyword. RMAN ignores any I/O errors. For example:

DELETE FORCE NOPROMPT BACKUPSET TAG 'weekly_bkup';

Crosschecking and Deleting on Multiple RMAN Channels

This section contains these topics:

• About Allocating Multiple RMAN Channels for Maintenance Commands
• How RMAN Crosschecks and Deletes on Multiple Channels
• Crosschecking Disk and Tape Channels with One Command: Example
• Crosschecking on Multiple Oracle Real Application Cluster Nodes: Example
• Deleting on Disk and Tape Channels with One DELETE Command: Example
• Releasing Multiple Channels: Example

About Allocating Multiple RMAN Channels for Maintenance Commands

You can configure or manually allocate multiple maintenance channels before issuing CROSSCHECK or DELETE commands. RMAN searches for each backup on all channels that have the same device type as the channel used to create the backup. The multichannel feature is designed for use in these scenarios:

• To crosscheck or delete of all backups, both on disk and tape, with a single command;
• To make crosschecking and deleting work correctly in an Oracle Real Application Cluster (RAC) configuration in which each backup exists only on one node.

How RMAN Crosschecks and Deletes on Multiple Channels

When you configure or manually allocate multiple maintenance channels and run a CROSSCHECK or DELETE command, RMAN performs the crosscheck or delete on all channels that have the appropriate device type.

For example, assume that you prefer to manually allocate channels rather than use configured channels. You have a media manager configured, but have not yet made backups to tape. You have created only one backup of a database to disk, as follows:

RUN 
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'SYS/sys_pwd@node2';
  BACKUP DATABASE;
}

Assume that you issue the following series of commands at the RMAN prompt:

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node1';
AlLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node2';
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP OF DATABASE;

RMAN checks the first two channels because they both have the device type of disk and finds the backup on the second channel. However, RMAN does not perform a crosscheck on the third sbt channel because you have not yet made backups with a media manager.

Crosschecking Disk and Tape Channels with One Command: Example

RMAN can perform crosschecks on more than one media with a single command. Assume that you have an sbt channel configured as follows:

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

In this case you can run the following command to perform a crosscheck on both DISK and sbt:

CROSSCHECK BACKUP OF DATABASE;

RMAN uses both the sbt channel and the preconfigured DISK channel to perform the crosscheck. Sample output follows:

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
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=13c5erba_1_1 recid=33 stamp=408382829
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=14c5erce_1_1 recid=34 stamp=408382863
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-674966176-20000915-00 recid=35 stamp=408382869

If you do not have an automatic sbt channel configured, then can also manually allocate maintenance channels on disk and tape as in the following example:

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP OF DATABASE;

Note that you do not have to manually allocate a disk channel because RMAN uses the preconfigured disk channel.

Crosschecking on Multiple Oracle Real Application Cluster Nodes: Example

This feature is useful in an Oracle Real Application Cluster (RAC) configuration in which tape backups exist on various nodes in the cluster and are only visible on the nodes where they were created.

When crosschecking on multiple nodes, it is important to allocate channels at every node where backups were created. If you omit a channel for a node, or you set the parallelism to a value less than the number of nodes, then the backups created on that node will be marked EXPIRED in the repository. For example, you can configure RMAN for use with RAC nodes as follows:

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'SYS/oracle@node_1';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK CONNECT 'SYS/oracle@node_2';

Then, crosscheck the cluster nodes with the following command:

CROSSCHECK BACKUP;

Deleting on Disk and Tape Channels with One DELETE Command: Example

You can also perform deletions on all allocated channels. In the following example, you configure an sbt channel:

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

Then, you run a command to delete all backup sets from disk and tape:

DELETE BACKUPSET;

RMAN uses both the sbt channel and the preconfigured DISK channel when deleting (sample output follows). Note that RMAN prompts you for confirmation before deleting any files:

using channel ORA_SBT_TAPE_1
using channel ORA_DISK_1

List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
388     387     1   1   AVAILABLE   SBT_TAPE    12c5erb2_1_1
397     396     1   1   UNAVAILABLE SBT_TAPE    13c5erba_1_1
424     423     1   1   AVAILABLE   SBT_TAPE    14c5erce_1_1
428     427     1   1   AVAILABLE   SBT_TAPE    c-674966176-20000915-00
433     432     1   1   AVAILABLE   DISK        /oracle/dbs/16c5esv4_1_1
437     436     1   1   AVAILABLE   DISK     /oracle/dbs/c-674966176-20000915-01

Do you really want to delete the above objects (enter YES or NO)? y
deleted backup piece
backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp=408384484
deleted backup piece
backup piece handle=/oracle/dbs/c-674966176-20000915-01 recid=37 stamp=408384496
deleted backup piece
backup piece handle=12c5erb2_1_1 recid=32 stamp=408382820
deleted backup piece
backup piece handle=13c5erba_1_1 recid=33 stamp=408382829
deleted backup piece
backup piece handle=14c5erce_1_1 recid=34 stamp=408382863
deleted backup piece
backup piece handle=c-674966176-20000915-00 recid=35 stamp=408382869

The following example manually allocates DISK and sbt maintenance channels and then deletes specific backup sets from both disk and tape:

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
DELETE BACKUPSET 1,2,3,4,5;

RMAN looks for the specified backup sets on the channels and deletes any it finds. If RMAN does not find a backup on any channel, then RMAN marks the object as deleted in the control file and deletes the recovery catalog record (if you use a recovery catalog).

Releasing Multiple Channels: Example

You can release all allocated maintenance channels by running this command:

RELEASE CHANNEL;

Deleting a Database with RMAN

You may need to remove a database from the operating system. For example, you create a test database and then no longer have a use for it.

The DROP DATABASE command requires that RMAN be connected to the target database and that the target database be mounted. The command does not require connection to the recovery catalog. If RMAN is connected to the recovery catalog, and if you specify the option INCLUDE COPIES AND BACKUPS, then RMAN also unregisters the database.

To drop the database:

1. Connect RMAN to the target database and (optionally) recovery catalog. For example:

   rman TARGET / CATALOG rman/rman@catdb
   
   

2. Catalog all backups that are associated with the database. For example, the following commands catalogs files in the flash recovery area, and then in a secondary archiving destination:

   RMAN> CATALOG START WITH '+disk1';    # all files from flash recovery area 
                                         # (stored on ASM disk)
   RMAN> CATALOG START WITH '/arch_dest2';  # all files from second arch dest
   
   

3. Delete all backups and copies associated with the database. For example:

   RMAN> DELETE BACKUPSET; # deletes all backups
   RMAN> DELETE COPY; # delete all image copies (including archived logs)
   
   

4. Remove the database from the operating system (and automatically unregister it from the recovery catalog if you are connected to the catalog). For example:

   DROP DATABASE; # delete all database files and unregister the database 
   

Changing the Status of a Backup Record

This section contains the following sections:

• Marking a Backup AVAILABLE or UNAVAILABLE
• Exempting a Backup from the Retention Policy

Marking a Backup AVAILABLE or UNAVAILABLE

Run the CHANGE ... UNAVAILABLE command when a backup cannot be found or has migrated offsite. RMAN does not use files marked UNAVAILABLE in RESTORE or RECOVER commands. If the file is later found or returns to the main site, then you can mark it available again by issuing CHANGE ... AVAILABLE.

Note that files in the flash recovery area cannot be marked as UNAVAILABLE.

To mark a file's status in the repository as UNAVAILABLE or AVAILABLE:

1. Issue a LIST command to determine the availability status of RMAN backups. For example, issue:

   LIST BACKUP;
   
   

2. Run CHANGE with the UNAVAILABLE or AVAILABLE keyword to update its status in the RMAN repository. For example, enter:

   CHANGE DATAFILECOPY '/tmp/control01.ctl' UNAVAILABLE;
   CHANGE COPY OF ARCHIVELOG SEQUENCE BETWEEN 1000 AND 1012 UNAVAILABLE;
   CHANGE BACKUPSET 12 UNAVAILABLE;
   CHANGE BACKUP OF SPFILE TAG "TAG20020208T154556" UNAVAILABLE;
   CHANGE DATAFILECOPY '/tmp/system01.dbf' AVAILABLE;
   CHANGE BACKUPSET 12 AVAILABLE;
   CHANGE BACKUP OF SPFILE TAG "TAG20020208T154556" AVAILABLE;
   

   See Also: Oracle Database Recovery Manager Reference for CHANGE command syntax

Exempting a Backup from the Retention Policy

The BACKUP ... KEEP command can create a backup that is retained for a different period of time from that specified by the configured retention policy. The backup is still a fully valid backup, however, and can be restored just as any other RMAN backup. This type of backup is called a long-term backup.

Specify KEEP ... LOGS to save archived logs for a possible incomplete recovery and KEEP ... NOLOGS not to save archived logs for a possible incomplete recovery. Note that NOLOGS is not valid with an inconsistent backup.

Use the CHANGE command to alter the KEEP status of a backup that already exists. For example, you may decide that you no longer want to keep a long-term backup. The same options available for BACKUP ... KEEP are available with CHANGE ... KEEP.

Note that you cannot set KEEP attributes on files stored in the flash recovery area.

To alter the KEEP status of a backup:

Issue CHANGE ... KEEP to define a different retention period for this backup, or CHANGE ... NOKEEP to let the retention policy apply to this file.

This example allows a backup set to be marked obsolete by the retention policy:

CHANGE BACKUPSET 231 NOKEEP;

This example makes a datafile copy exempt from the retention policy for 180 days (6 months):

CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL 'SYSDATE+180';

Cataloging Archived Logs and User-Managed Copies

You can make RMAN aware of the existence of archived logs that are not recorded in the repository as well as file and backup piece copies that are created through means other than RMAN. This section contains the following topics:

• About Cataloging Archived Logs and User-Managed Copies
• Cataloging User-Managed Datafile Copies
• Cataloging Backup Pieces
• Cataloging All Files in a Disk Location

About Cataloging Archived Logs and User-Managed Copies

The target database control file keeps records of all archived logs generated by the target database as well as all RMAN backups. The purpose of the CATALOG command is to add metadata to the repository when it does not have a record of files that you want RMAN to know about.

Run the RMAN CATALOG command when:

• You use an operating system utility to make copies of datafiles, archived logs, or backup pieces. In the case, the repository has no record of them.
• You perform recovery with a backup control file and you change the archiving destination or format during recovery. In this situation, the repository will not have information about archived logs needed for recovery. Hence, you must catalog these logs.
• You want to catalog datafile copy as a level 0 backup, thus enabling you to perform an incremental backup later by using the datafile copy as the base of an incremental backup strategy
• You want to catalog user-managed copies of Oracle7 database files created before you migrated to a higher release, or of Oracle8 and higher database files created before you started to use RMAN. These datafile copies enable you to recover the database if it crashes after migration but before you have a chance to take a backup of the migrated database.

Whenever you make a user-managed copy, for example, by using the UNIX cp command to copy a datafile, make sure to catalog it. When making user-managed copies, you can use the ALTER TABLESPACE ... BEGIN/END BACKUP statement to make datafile copies off an online tablespace. Although RMAN does not create such datafile copies, you can use the CATALOG command to add them to the recovery catalog so that RMAN is aware of them.

For a user-managed copy to be cataloged, it must be:

• Accessible on disk
• A complete image copy of a single file
• Either a datafile copy, control file copy, archived redo log copy, or backup piece copy

For example, if you store datafiles on mirrored disk drives, then you can create a user-managed copy by breaking the mirror. In this scenario, use the CATALOG command to notify RMAN of the existence of the user-managed copy after breaking the mirror. Before reforming the mirror, run a CHANGE ... UNCATALOG command to notify RMAN that the file copy no longer exists.

Cataloging User-Managed Datafile Copies

Use the CATALOG command to propagate information about user-managed copies to the RMAN repository. After the files are cataloged, you can run LIST or query V$BACKUP_FILES to confirm.

To create and catalog a user-managed copy of a datafile:

1. Make a datafile copy with an operating system utility. ALTER TABLESPACE BEGIN/END BACKUP is necessary if the database is open and the datafiles are online while the backup is in progress. This example backs up an online datafile.

   SQL> ALTER TABLESPACE users BEGIN BACKUP;
   % cp $ORACLE_HOME/oradata/trgt/users01.dbf /tmp/users01.dbf;
   SQL> ALTER TABLESPACE users END BACKUP;
   
   

2. After connecting to the target database and, if desired, the recovery catalog, run the CATALOG command. For example, enter:

   CATALOG DATAFILECOPY '/tmp/users01.dbf';
   

   See Also: Oracle Database Recovery Manager Reference for CATALOG command syntax

Cataloging Backup Pieces

You can catalog backup pieces on disk. This technique is useful if you use an operating system utility to copy backup pieces from location to another on the same host, or from one host to another. You can even catalog a backup piece from a prior incarnation of the database. After a backup piece is cataloged, you can display its metadata by querying V$BACKUP_PIECE, V$BACKUP_SET, V$BACKUP_DATAFILE, V$BACKUP_REDOLOG, and V$BACKUP_SPFILE.

To catalog a backup piece:

1. After connecting RMAN to the target database, catalog the filenames of the backup pieces. For example:

   CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1';
   
   

   Note: If you are cataloging backup pieces from prior to Oracle9i, you can achieve significant performance gains by cataloging the highest copy numbers first. Otherwise, RMAN must examine all pieces to determine the correct order. For example, catalog copy 3 of a piece before copy 2: CATALOG BACKUPPIECE '/disk2/09dtq55d_1_3', '/disk2/09dtq55d_1_2';

   Backup pieces from Oracle Database Release 10g are not affected by this issue and can be cataloged in any order.

   ---

SELECT HANDLE FROM V$BACKUP_PIECE;

RMAN> CATALOG RECOVERY AREA; # catalog all files in the recovery area
RMAN> CATALOG START WITH '+disk'; # catalog all files from an ASM disk group
RMAN> CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory

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