Skip Headers

Oracle® Database Backup and Recovery Basics
10g Release 1 (10.1)

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

Go to previous page
Previous
Go to next page
Next
View PDF

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

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.

See Also:

Oracle Database Administrator's Guide for a conceptual overview of the control file and more details about managing control files.

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.

See Also:

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.


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.


Managing the Overwriting of Control File Records: Scenario

Assume the following scenario:

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:

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:

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

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:

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;
See Also:

Oracle Database Recovery Manager Reference for CROSSCHECK command syntax

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

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:

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';
See Also:

Crosschecking and Deleting on Multiple RMAN Channels

This section contains these topics:

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:

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.


Note:

The DELETE EXPIRED command issues warnings if any objects marked as EXPIRED actually exist. In rare cases, the repository can mark an object as EXPIRED even though the object exists. For example, a directory containing an object 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.


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.

See Also:

Oracle Database Backup and Recovery Advanced User's Guide to learn how to use the SQL*Plus DROP DATABASE command

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

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.


Note:

The KEEP FOREVER clause requires the use of a recovery catalog.


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

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:

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:

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;
See Also:

Oracle Database Recovery Manager Reference for CATALOG BACKUPPIECE restrictions

Cataloging All Files in a Disk Location

If you use Automatic Storage Management (ASM), an Oracle Managed Files framework, or the flash recovery area, then you may need a way to recatalog files that are known to the disk management system but are no longer listed in the RMAN repository. Files can be orphaned when the intended mechanisms for tracking filenames fails due to media failure, software bug, or user error.

The CATALOG START WITH command enables you to search through all files in an ASM disk group, Oracle Managed Files location, or traditional file system directory and investigate those that are not recorded in the RMAN repository. If the command can catalog a file, then it will; if it cannot catalog it, then it makes its best guess about the contents of the skipped file.

The CATALOG RECOVERY AREA command will catalog all files in the flash recovery area. If there are any orphaned files in the recovery area, they will be added to the RMAN repository.

To catalog all files in a disk location:

After connecting RMAN to the target database, specify the disk location whose files you want to catalog. For example:

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

Note:

Wildcard characters are not legal in the START WITH clause.


Uncataloging RMAN Records

This section contains the following topics:

About Uncataloging RMAN Records

Run the CHANGE ... UNCATALOG command to perform the following actions on RMAN repository records:

RMAN does not touch the specified physical files: it only alters the repository records for these files.

You can use this command when you have deleted a backup through a means other than RMAN. For example, if you delete archived redo logs with an operating system utility, then remove the record for this log from the repository by issuing CHANGE ARCHIVELOG ... UNCATALOG.

Removing Records for Files Deleted with Operating System Utilities

To remove catalog records for files deleted with operating system utilities, run the CHANGE ... UNCATALOG command.

To remove the catalog record for a backup deleted with an operating system utility:

  1. Run a CHANGE ... UNCATALOG command for the backups that you deleted from the operating system with operating system commands. This example deletes repository references to disk copies of the control file and datafile 1:
    CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG;
    CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG;
    
    
  2. Optionally, view the relevant recovery catalog view, for example, RC_DATAFILE_COPY or RC_CONTROLFILE_COPY, to confirm that a given record was removed. For example, this query confirms that the record of copy 4833 was removed:
    SELECT CDF_KEY, STATUS 
    FROM RC_DATAFILE_COPY 
    WHERE CDF_KEY = 4833;
    
    CDF_KEY    STATUS
    ---------- ------
    0 rows selected.
    
    

Flash Recovery Area Maintenance

While the flash recovery area is largely self-managing, there are some situations in which DBA intervention may be required.

Resolving a Full Flash Recovery Area

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

You may also need to consider changing your backup retention policy and, if using Data Guard, consider changing your archivelog deletion policy.

See Also:

Chapter 4, "Making Backups with Recovery Manager" for more on how to decide on a retention policy, and Oracle Data Guard Concepts and Administration for more on archivelog deletion policy with Data Guard.



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, you can follow this procedure:

  1. Invoke SQL*Plus to change the DB_RECOVERY_FILE_DEST initialization parameter. For example:
    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. The permanent files (control files and online redo log files), flashback logs and transient files can be left in the old flash recovery area location. The database will delete the transient files from the old flash recovery area location as they become eligible for deletion.

    If you need to actually move your current permanent files, transient files, or flashback logs to the new flash recovery area, see Oracle Database Backup and Recovery Advanced User's Guide . The process outlined there for moving database files into and out of an ASM disk group with RMAN will also work when moving files into and out of a flash recovery area location.

    See Also:

    "Backing Up to the Flash Recovery Area and to Tape: Basic Scenarios"



Oracle will clean up transient files remaining in the old flash recovery area location as they become eligible for deletion.

Flash Recovery Area Behavior When Instance Crashes During File Creation

As a rule, the flash recovery area is self-maintaing, but when an instance crashes during the creation of a file in the flash recovery area, Oracle may leave the file in the flash recovery area. When this occurs, you will see the following error in the alert log:

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

where location is the location of the flash recovery area.

In such a situation, you should use the RMAN command CATALOG RECOVERY AREA to re-catalog any such files so that they appear in the RMAN repository. If the file header of the file in question is corrupted, then you will have to delete the file manually using an operating system-level utility.