|Oracle® Database Backup and Recovery Basics
10g Release 1 (10.1)
Part Number B10735-01
This chapter describes how to manage the RMAN repository and some maintenance tasks related to the flash recovery area.
This chapter contains these topics:
Oracle Database Backup and Recovery Advanced User's Guide for more in-depth information about managing the RMAN repository when using 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.
Oracle Database Administrator's Guide for a conceptual overview of the control file and more details about managing control files.
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.
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.
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.
CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum age in days of a record before it can be overwritten:
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
Regardless of whether you use a recovery catalog, never use RMAN when
Assume the following scenario:
CONTROL_FILE_RECORD_KEEP_TIMEis set to
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:
alert.logto make sure that Oracle is not overwriting control file records.
Oracle Database Backup and Recovery Advanced User's Guide for a conceptual overview of control file records and how they are re-used
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:
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:
BACKUP RECOVERY AREA, or by changing the retention policy to a shorter recovery window or lower degree of redundancy.
RMAN provides several commands that enable you to check and delete records of backups as well as physically remove 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:
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
EXPIRED. View the status of backups in one of the following locations:
RC_ARCHIVED_LOG, and so forth
You can use the
LIST command to report your backups and then use the
CROSSCHECK command to check that these files still exist. The
EXPIRED command deletes repository records for backups that fail the crosscheck.
To crosscheck specified backups:
LISTcommand. For example, issue:
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
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;
Oracle Database Recovery Manager Reference for
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:
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
To delete backups and remove their repository records:
LISToutput to obtain primary keys of backups. For example:
DELETEcommand to eliminate the specified physical files and their repository records. For example:
BACKUP(which deletes backup sets, proxy copies, and image copies),
COPY(which deletes only image copies), or
ARCHIVELOGas 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
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
EXPIRED command to remove expired records. If the expired files still exist, then the
EXPIRED command terminates with an error.
To delete expired repository records:
CROSSCHECKcommand. For example, issue:
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:
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
If you specify the
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:
OBSOLETE command without any options to delete the objects defined as obsolete by the retention policy, for example:
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.
You can run the
WINDOW commands to delete obsolete backups. The redundancy or recovery window setting on the
DELETE command overrides setting on the
To specify which backups are obsolete and should be deleted:
OBSOLETE command with the
WINDOW options. These options define what is obsolete during the delete job. For example, enter:
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:
This section contains these topics:
You can configure or manually allocate multiple maintenance channels before issuing
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:
When you configure or manually allocate multiple maintenance channels and run a
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:
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.
RMAN can perform crosschecks on more than one media with a single command. Assume that you have an
sbt channel configured as follows:
In this case you can run the following command to perform a crosscheck on both
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:
Note that you do not have to manually allocate a disk channel because RMAN uses the preconfigured disk channel.
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:
You can also perform deletions on all allocated channels. In the following example, you configure an
Then, you run a command to delete all backup sets from disk and tape:
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
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).
You can release all allocated maintenance channels by running this command:
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.
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
BACKUPS, then RMAN also unregisters the database.
Oracle Database Backup and Recovery Advanced User's Guide to learn how to use the SQL*Plus
To drop the database:
This section contains the following sections:
UNAVAILABLE command when a backup cannot be found or has migrated offsite. RMAN does not use files marked
RECOVER commands. If the file is later found or returns to the main site, then you can mark it available again by issuing
Note that files in the flash recovery area cannot be marked as
To mark a file's status in the repository as UNAVAILABLE or AVAILABLE:
LISTcommand to determine the availability status of RMAN backups. For example, issue:
AVAILABLEkeyword 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;
Oracle Database Recovery Manager Reference for
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.
LOGS to save archived logs for a possible incomplete recovery and
NOLOGS not to save archived logs for a possible incomplete recovery. Note that
NOLOGS is not valid with an inconsistent backup.
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
KEEP are available with
Note that you cannot set
KEEP attributes on files stored in the flash recovery area.
To alter the KEEP status of a backup:
KEEP to define a different retention period for this backup, or
NOKEEP to let the retention policy apply to this file.
This example allows a backup set to be marked obsolete by the retention policy:
This example makes a datafile copy exempt from the retention policy for 180 days (6 months):
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:
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
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
UNCATALOG command to notify RMAN that the file copy no longer exists.
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:
BACKUPis necessary if the database is open and the datafiles are online while the backup is in progress. This example backs up an online datafile.
CATALOGcommand. For example, enter:
Oracle Database Recovery Manager Reference for
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
To catalog a backup piece:
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:
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;
Oracle Database Recovery Manager Reference for
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.
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.
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
This section contains the following topics:
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
To remove catalog records for files deleted with operating system utilities, run the
To remove the catalog record for a backup deleted with an operating system utility:
UNCATALOGcommand 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
CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG; CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG;
RC_CONTROLFILE_COPY, to confirm that a given record was removed. For example, this query confirms that the record of copy
SELECT CDF_KEY, STATUS FROM RC_DATAFILE_COPY WHERE CDF_KEY = 4833; CDF_KEY STATUS ---------- ------ 0 rows selected.
While the flash recovery area is largely self-managing, there are some situations in which DBA intervention may be required.
You have a number of choices on how to resolve a full flash recovery area when there are no files eligible for deletion:
DB_RECOVERY_FILE_DEST_SIZEto reflect the new space.
BACKUP RECOVERY AREA, to back up the contents of the flash recovery area to a tertiary device such as tape.
CROSSCHECKcommand to have RMAN re-check the contents of the flash recovery area and identify expired files, and then use the
DELETE EXPIREDcommand to remove missing files from the RMAN repository.)
You may also need to consider changing your backup retention policy and, if using Data Guard, consider changing your archivelog deletion policy.
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.
If you need to move the flash recovery area of your database to a new location, you can follow this procedure:
DB_RECOVERY_FILE_DESTinitialization 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.
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.
Oracle will clean up transient files remaining in the old flash recovery area location as they become eligible for deletion.
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.
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.