Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1) Part Number B10735-01 |
|
|
View PDF |
This chapter describes how to manage the RMAN repository and some maintenance tasks related to the flash recovery area.
This chapter contains these topics:
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 |
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. |
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:
|
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 |
Assume the following scenario:
CONTROL_FILE_RECORD_KEEP_TIME
is set to 14
.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.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 |
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:
DB_BLOCK_SIZE
.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 AVAILABLE
, UNAVAILABLE
, and EXPIRED
. View the status of backups in one of the following locations:
LIST
command outputV$BACKUP_FILES
RC_DATAFILE_COPY
, RC_ARCHIVED_LOG
, and so forth
Note: The |
See Also:
|
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:
LIST
command. For example, issue:
LIST BACKUP; # lists all backup sets, proxy copies, and image copies
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
.
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 |
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:
Note: Backups with |
See Also:
|
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:
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
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;
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
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:
CROSSCHECK
command. For example, issue:
CROSSCHECK BACKUP; # checks backup sets and copies on configured channels
DELETE EXPIRED BACKUP;
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:
CONFIGURE
commandDELETE
OBSOLETE
commandThe 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
.
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.
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;
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:
|
This section contains these topics:
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:
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.
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.
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;
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).
You can release all allocated maintenance channels by running this command:
RELEASE CHANNEL;
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 |
To drop the database:
rman TARGET / CATALOG rman/rman@catdb
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
RMAN> DELETE BACKUPSET; # deletes all backups RMAN> DELETE COPY; # delete all image copies (including archived logs)
DROP DATABASE; # delete all database files and unregister the database
This section contains the following sections:
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:
LIST
command to determine the availability status of RMAN backups. For example, issue:
LIST BACKUP;
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 |
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';
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 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.
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:
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;
CATALOG
command. For example, enter:
CATALOG DATAFILECOPY '/tmp/users01.dbf';
See Also:
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 V$BACKUP_PIECE
, V$BACKUP_SET
, V$BACKUP_DATAFILE
, V$BACKUP_REDOLOG
, and V$BACKUP_SPFILE
.
To catalog a backup piece:
CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1';
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 |
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
This section contains the following topics:
Run the CHANGE
...
UNCATALOG
command to perform the following actions on RMAN repository records:
DELETED
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
.
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:
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;
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.
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_SIZE
to reflect the new space.BACKUP RECOVERY AREA
, to back up the contents of the flash recovery area to a tertiary device such as tape.CROSSCHECK
command to have RMAN re-check the contents of the flash recovery area and identify expired files, and then use the DELETE EXPIRED
command to 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.
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. |
If you need to move the flash recovery area of your database to a new location, you can follow this procedure:
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.
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.
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.