3
Managing the Recovery Manager Repository

SQL> EXECUTE dbms_rcvcat.unregisterdatabase(db_key, db_id)

For example, enter:

SQL> EXECUTE dbms_rcvcat.unregisterdatabase(1 , 1237603294)

Resetting the Recovery Catalog

Before you can use RMAN again with a target database that you have opened with the RESETLOGS option, notify RMAN that you have reset the database incarnation. The reset database command directs RMAN to create a new database incarnation record in the recovery catalog. This new incarnation record indicates the current incarnation. RMAN associates all subsequent backups and log archiving done by the target database with the new database incarnation.

If you issue the ALTER DATABASE OPEN RESETLOGS statement but do not reset the database, then RMAN cannot access the recovery catalog because it cannot distinguish between a RESETLOGS command and an accidental restore of an old control file. By resetting the database, you inform RMAN that the database has been opened with the RESETLOGS option.

In the rare situation in which you wish to undo the effects of opening with the RESETLOGS option by restoring backups of a prior incarnation of the database, use the reset database to incarnation key command to change the current incarnation to an older incarnation.

To reset the recovery catalog to an older incarnation:

1. Specify the primary key of the desired database incarnation. Obtain the incarnation key value by issuing a list command:

   list incarnation;
   

   
   
   List of Database Incarnations
   DB Key  Inc Key   DB Name   DB ID       CUR    Reset SCN    Reset Time
   ------- -------   -------   ------      ---    ----------   ----------
   1       2         PROD1     1224038686  NO     1            02-JUL-98
   1       582       PROD1     1224038686  YES    59727        10-JUL-98
   
   
   

2. Reset the database to the old incarnation. For example, enter:

   reset database to incarnation 2;
   

3. After resetting the database, issue restore and recover commands to restore and recover the database files from the prior incarnation, then open the database with the RESETLOGS option. For example, enter:

   run {
        allocate channel ch1 type disk;
        restore database;
        recover database;
        alter database open resetlogs;
   }
   

   See Also: "reset" for reset database command syntax, "list" for list command syntax.

Changing the Availability of a Backup or File Copy

The unavailable option provides for cases when a backup or copy cannot be found or has migrated offsite. A file that is marked UNAVAILABLE is not used in a restore or recover command. If the file is later found or returns to the main site, then you can mark it available again by using the available operand. Note that you do not need to allocate a channel of type maintenance for this operation.

To mark a backup piece or copy as available or unavailable:

1. Issue a change ... unavailable command to mark a backup or copy as UNAVAILABLE. For example, enter:

   change datafilecopy '/oracle/backup/cf_c.f' unavailable;
   change backupset 12 unavailable;
   

2. If a previously unavailable file is reinstated, issue change ... available to change its status back to AVAILABLE.

   change datafilecopy '/oracle/backup/cf_c.f' available;
   change backupset 12 available;
   

   See Also: "change" for change command syntax.

Crosschecking the RMAN Repository

Because backups and copies can disappear from disk or tape or become corrupted, the RMAN metadata repository can contain outdated information. To ensure that data about backup sets and image copies in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog, perform a crosscheck.

Use either the change ... crosscheck or crosscheck backup command to check the specified files. Note that these commands do not delete operating system files or remove repository records; you must use separate commands for those operations.

The following table explains the difference between the crosscheck commands:

Command	Catalog Needed?	Purpose
change ... crosscheck	Only for backupset and backuppiece options	To determine whether the backups or copies exist. If RMAN cannot find backup pieces, it marks them as EXPIRED. It marks all other types of absent files--image copies and archived redo logs--as DELETED. If the files are on disk, RMAN queries the file headers. For other device types, RMAN queries the media manager to see if the file exists in the media catalog.
crosscheck backup	No	To determine whether backups stored on disk or tape exist. Backups are either backup sets or media-managed proxy copies. This command checks only backup sets marked AVAILABLE or EXPIRED, either by examining the backup pieces for type disk or by querying the media manager for type 'sbt_tape'. It only processes backups created on the specified channel. RMAN does not delete backup pieces that it cannot find, but marks them as EXPIRED.

Crosschecking Backups

Use the crosscheck feature to check the status of a backup on disk or tape. If the backup is on disk, the change backupset ... crosscheck and crosscheck backup commands determine whether the header of the backup piece is valid; if on tape, the commands simply check that the backups exist.

If a backup piece is unreadable or absent, then RMAN marks the backup piece EXPIRED in the output of the list command and the recovery catalog views. If it was marked EXPIRED but is now available, RMAN marks the backup piece as AVAILABLE in the output of the list command and the recovery catalog views.

Use change backupset ... crosscheck when you want to provide a list of backup sets or pieces to check; use crosscheck backup when you wish to restrict the crosscheck to a specified device type, object type, or date range and let RMAN generate the list of backup sets or pieces.

To provide a list of backups for a crosscheck:

1. Allocate a channel of type maintenance:

   allocate channel for maintenance type 'sbt_tape';
   

2. Identify the desired backup piece, backup set, or proxy copy that you want to check by issuing a list command:

   list backup;
   

3. Check whether the specified backup sets exist. This example checks whether backup sets with the primary keys of 1338, 1339, and 1340 still exist:

   RMAN> change backupset 1338, 1339, 1340 crosscheck;
   

   
   
   RMAN-03022: compiling command: change
   RMAN-08074: crosschecked backup piece: found to be 'EXPIRED'
   RMAN-08517: backup piece handle=/oracle/dbs/2eafnuj3_1_1 recid=77 stamp=352057957
   RMAN-08074: crosschecked backup piece: found to be 'AVAILABLE'
   RMAN-08517: backup piece handle=/oracle/dbs/2dafnuj2_1_1 recid=78 stamp=352057957
   RMAN-08074: crosschecked backup piece: found to be 'AVAILABLE'
   RMAN-08517: backup piece handle=/oracle/dbs/2fafnuj3_1_1 recid=79 stamp=352057960
   
   
   

   If a backup set is no longer available, RMAN marks it as EXPIRED. If it was marked EXPIRED and is now available, RMAN marks it AVAILABLE.

4. Release the allocated maintenance channel:

   release channel;
   

To let RMAN generate the list of backups for a crosscheck:

1. Allocate a channel of type maintenance:

   allocate channel for maintenance type 'sbt_tape';
   

2. 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 tbs_8.f over the last six months:

   crosscheck backup of datafile "/oracle/dbs/tbs_8.f" completed after 'SYSDATE-180';
   

   If a backup set is no longer available, RMAN marks it as EXPIRED. If it was marked EXPIRED and is now available, RMAN marks it AVAILABLE.

3. Release the allocated maintenance channel:

   release channel;
   

Crosschecking Image Copies

Use the change ... crosscheck command to determine whether image copies of datafiles, control files, or archived redo logs on disk or tape are valid. If RMAN is unable to find the specified image copy or archived redo log, it updates its status to DELETED.

RMAN considers archived redo logs as image copies. If for some reason one or more archived redo logs becomes unavailable, issue a change archivelog all crosscheck command so that RMAN updates the STATUS column of the absent logs to DELETED. You do not need to use a recovery catalog to execute this command.

To crosscheck image copies:

1. Connect to RMAN either with or without a recovery catalog. For example, enter one of the following:

   % rman target / nocatalog
   % rman target / catalog rman/rman@rcat
   
   

2. Identify the image copy that you want to check by issuing a list command. This example lists all recorded image copies and archived redo logs:

   list copy of database archivelog all;
   

   
   
   List of Datafile Copies
   Key     File S Completion time Ckp SCN    Ckp time    Name
   ------- ---- - --------------- ---------- ----------  ------
   1262    1    A 18-AUG-98       219859     14-AUG-98   /oracle/dbs/copy/tbs_01.f
   
    
   
   List of Archived Log Copies
   Key     Thrd Seq     S Completion time Name
   ------- ---- ------- - --------------- ------------------------------------
   789     1    1       A 14-JUL-98       /oracle/work/arc_dest/arcr_1_1.arc
   790     1    2       A 11-AUG-98       /oracle/work/arc_dest/arcr_1_2.arc
   791     1    3       A 12-AUG-98       /oracle/work/arc_dest/arcr_1_3.arc
   
   
   

3. Use change ... crosscheck to check whether the specified copy exists. If not, RMAN updates its status to DELETED. This example checks whether the datafile copy with primary key 1262 exists:

   change datafilecopy 1262 crosscheck;
   

   
   
   RMAN-03022: compiling command: change
   RMAN-06154: validation succeeded for datafile copy
   RMAN-08513: datafile copy filename=/oracle/dbs/copy/tbs_01.f recid=1 stamp=351194732
   
   
   

If RMAN is unable to validate the copy, you will see:

RMAN-06153: validation failed for datafile copy

To update the RMAN repository after archived redo logs have been removed:

1. Connect to RMAN with or without a catalog. For example, enter either:

   % rman target / nocatalog
   % rman target / catalog rman/rman@rcat
   
   

2. Issue a change ... crosscheck command to update the repository records for the absent archived redo logs. This example crosschecks all archived redo logs:

   change archivelog all crosscheck;
   

   See Also: "crosscheck" for crosscheck command syntax "change" for change command syntax "list" for list command syntax

Deleting Backups and Copies and Updating Their Status in the RMAN Repository

You can use RMAN to delete backups, copies, and archived logs and update their status in the repository to DELETED status or remove the records entirely.

Table 3-2 describes the functionality of the maintenance commands and scripts:

Table 3-2 Maintenance Commands and Scripts (Page 1 of 2)

To update the catalog record for a backup or copy deleted with an operating system utility:

1. Allocate a channel of type maintenance:

   allocate channel for maintenance type disk;
   

2. Issue a change ... uncatalog command for the backups or copies that you deleted from the operating system using operating system commands. This example removes references to copies of the control file and datafile 1 from the repository:

   change controlfilecopy '/oracle/backup/cf_c.f' uncatalog;
   change datafilecopy '/oracle/backup/df_1_c.f' uncatalog;
   

3. Release the allocated channel:

   release channel;
   

To physically delete backups and image copies and remove their repository records:

This procedure does not require the use of a recovery catalog.

The behavior of change ... delete differs depending on what you are deleting. If you are deleting backups and image copies (but not archived logs), then change ... delete deletes the physical files and removes the records for these files from the repository.

If you are deleting archived redo logs and you use a catalog, then the outcome of the following procedure depends on the compatibility setting of the recovery catalog (see "Setting Recovery Catalog Compatibility"), as explained in the following table:

If compatibility is set to	Then
8.1.6 or higher	RMAN deletes the specified backups, copies, or archived logs and completely removes their records from the repository.
8.1.5 or lower	RMAN deletes the specified backups, copies, or archived logs and updates their repository records to status DELETED.

1. Check for the expired backup sets and copies. Use the list output to obtain their primary keys.

   list backup of database archivelog all; # lists backups of database files and logs
   list copy;
   

2. Allocate a channel of type delete:

   allocate channel for delete type disk;
   

3. Issue a change ... delete command to eliminate the specified physical files and the repository records. If you are deleting archived logs, then depending on the compatibility setting of the recovery catalog, this command either changes the recovery catalog record to status DELETED or removes the record altogether.

   This example deletes the backup piece with key 101, the control file copy with key 63, and all archived logs through log sequence 300 from disk:

   change backuppiece 101 delete;
   change controlfilecopy 63 delete;
   change archivelog until logseq = 300 delete;  # effect on catalog records for these
                                                 # logs depends on compatibility setting
   

4. Release the allocated maintenance channel:

   release channel;
   

To physically delete obsolete backups and copies and remove their repository records:

This procedure does not require the use of a recovery catalog. The script below works only on UNIX systems.

1. Change into the $ORACLE_HOME/rdbms/demo directory and edit the following shell script as needed:

   % vi rman1.sh
   

2. Execute the script:

   % rman1.sh
   
   

3. If desired, check deleted.log to see the command output.

To remove EXPIRED backup records in the catalog (and delete any existing expired backup pieces):

This procedure requires the use of a recovery catalog.

1. Optionally, perform a crosscheck operation (see "Crosschecking the RMAN Repository") to mark all inaccessible or absent backups as EXPIRED. The delete expired backup command only operates on expired backups.

2. Allocate a channel of type delete:

   allocate channel for delete type disk;
   

3. Issue a delete expired backup command to check for backups marked EXPIRED and remove their catalog records. This example updates all backups registered in the recovery catalog that are expired:

   delete expired backup;
   
   

   If the expired pieces exist, RMAN removes them from the operating system.

4. Release the allocated channel:

   release channel;
   

To remove image copy and archived redo log records from the recovery catalog (without physically deleting the files):

This procedure requires the use of a recovery catalog.

1. Check for the expired datafile copies, control file copies, or archived redo logs. Use the list output to obtain their primary keys. For example, enter:

   list copy;
   

2. Issue a change ... uncatalog command to remove references to the specified copies from the recovery catalog. Note that this command does not remove records of backup sets and backup pieces.

   This example removes records of copies of the control file and of the datafile copy with the primary key 4833:

   change controlfilecopy '/oracle/backup/cf_c.f' uncatalog;
   change datafilecopy 4833 uncatalog;
   

   Note that change ... uncatalog does not remove files from the operating system; it only removes recovery catalog records.

3. 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:

   SQL> SELECT cdf_key, status FROM rc_datafile_copy WHERE cdf_key = 4833;
   CDF_KEY    S
   ---------- -
   0 rows selected.
   
   

To remove all copy and backup records from the recovery catalog:

You can remove all recovery catalog records of deleted backups and copies at once using the $ORACLE_HOME/rdbms/prgrmanc.sql script. Only perform this operation if you do not want a historical record of what you have backed up.

1. Allocate a channel of type maintenance:

   allocate channel for maintenance type 'sbt_tape';
   

2. Issue change ... delete commands to update the desired records to DELETED status and remove the file from the operating system or media manager. Issue list commands or query the recovery catalog views to obtain primary keys for archived redo logs, backup sets, control file copies, or datafile copies.

   change backupset 100, 101, 102, 103 delete;
   

3. Release the allocated maintenance channel:

   release channel;
   

4. Start a SQL*Plus session and connect to the recovery catalog. This example connects to the database RCAT as user RMAN:

   % sqlplus rman/rman@rcat
   

5. Run the script prgrmanc.sql script, which is stored in the $ORACLE_HOME/rdbms/admin directory:

   SQL> @prgrmanc.sql
   

   RMAN removes all records with status DELETED from the recovery catalog.

To remove incarnation records from the recovery catalog:

1. Allocate a channel of type maintenance:

   allocate channel for maintenance type 'sbt_tape';
   

2. Issue change ... delete commands to remove unwanted backup pieces, archived redo logs, and image copies. Issue list commands or query the recovery catalog views to obtain primary keys for archived redo logs, backup sets, control file copies, or datafile copies.

   change backupset 100, 101, 102, 103 delete;
   

3. Release the allocated maintenance channel:

   release channel;
   

4. Start a SQL*Plus session and connect to the recovery catalog. This example connects to database RCAT as user RMAN:

   % sqlplus rman/rman@rcat
   

5. Obtain the DBINC_KEY values for the incarnations whose records you want to delete by querying the RC_DATABASE_INCARNATION recovery catalog view:

   SQL> SELECT * FROM rc_database_incarnation;
   

6. Execute the following DML statement, where key_value is the value of DBINC_KEY:

   SQL> DELETE FROM dbinc WHERE dbinc_key=key_value;
   

   RMAN will remove the specified incarnation records from the recovery catalog.

   See Also: "RC_DATABASE_INCARNATION" for more information about the RC_DATABASE_INCARNATION recovery catalog view.

Validating the Restore of Backups and Copies

A restore validation executes a restore test run without actually restoring the files. Test the restore of the entire database or individual tablespaces, datafiles, or control files. The restore ... validate and validate backupset commands test whether you can restore backups or copies. You should use:

• restore ... validate when you want RMAN to choose which backups or copies should be tested.

• validate backupset when you want to specify which backup sets should be tested.

  See Also: "restore" for restore command syntax, and "validate" for validate command syntax.

To let RMAN choose which backup sets or copies to validate:

1. If you want to validate the whole database, close it. If you want to validate individual files, then either close the database or take the individual datafiles offline. This example checks the status of the database, aborts the instance, and then mounts it:

   SQL> SELECT status FROM v$instance;
   

   
   
   STATUS 
   -------
   OPEN   
   1 row selected.
   
   SQL> STARTUP FORCE MOUNT;
   
   
   

2. Start RMAN and connect to the target database and optional recovery catalog database:

   % rman target / catalog rman/rman@rcat
   

3. If you do not want to validate the whole database, identify the backup sets and copies that you want to validate by issuing list commands, noting primary keys:

   list backupset; 
   list copy;
   

4. Validate the restore of the backup sets and copies. This example validates the restore of the backup control file, SYSTEM tablespace, and all archived redo logs from disk:

   run {
        allocate channel ch1 type disk;
        allocate channel ch2 type tape;
        restore controlfile validate;
        restore tablespace 'system' validate;
        restore archivelog all validate;
   }
   

5. Check the output. If you see an error message stack and then the following, you do not have a backup or copy of one of the files that you are validating:

   RMAN-06026: some targets not found - aborting restore
   

If you see an error message stack and output similar to the following, for example, then there is a problem with the restore of the specified file:

RMAN-03002: failure during compilation of command
RMAN-03013: command type: restore
RMAN-03007: retryable error occurred during execution of command: IRESTORE
RMAN-07004: unhandled exception during command execution on channel c1
RMAN-10035: exception raised in RPC: ORA-19505: failed to identify file 
            "oracle/dbs/1fafv9gl_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
RMAN-10031: ORA-19624 occurred during call to DBMS_BACKUP_RESTORE.RESTOREBACKUPPIECE

If you do not see an error stack, then RMAN successfully validated the files.

To specify which backup sets to validate:

1. Start RMAN and connect to the target database and optional recovery catalog database:

   % rman target / catalog rman/rman@rcat
   

2. Identify the backup sets that you want to validate by issuing list commands:

   list backup of database archivelog all; 
   

3. Validate the restore of the backup sets. This example validates the restore of the backup control file, SYSTEM tablespace, and all archived redo logs from disk:

   run {
        allocate channel ch1 type disk;
        validate backupset 1121;
   }
   

4. Check the output. If you see the RMAN-08024 message then RMAN successfully validated the restore of the specified backup set.

   RMAN-03022: compiling command: allocate
   RMAN-03023: executing command: allocate
   RMAN-08030: allocated channel: ch1
   RMAN-08500: channel ch1: sid=10 devtype=DISK
    
   RMAN-03022: compiling command: validate
   RMAN-03023: executing command: validate
   RMAN-08016: channel ch1: starting datafile backupset restore
   RMAN-08502: set_count=47 set_stamp=346169465 creation_time=08-OCT-98
   RMAN-08023: channel ch1: restored backup piece 1
   RMAN-08511: piece handle=/vobs/oracle/dbs/1faa483p_1_1 params=NULL
   RMAN-08024: channel ch1: restore complete
   RMAN-08031: released channel: ch1
   

Storing Scripts in the Recovery Catalog

A stored script is a sequence of RMAN commands stored within the recovery catalog. It provides a common repository of frequently executed collections of RMAN commands.

For example, you can collect the RMAN commands needed to perform nightly backups into a single script called nightly_bkup. Storing the script in the recovery catalog instead of in an operating system text file has the advantage that it is accessible to any DBA using RMAN, regardless of which machine RMAN is executed on.

RMAN allows you to:

• Create a script and store it in the recovery catalog.

• Execute a stored script.

• Replace a stored script.

• Delete a script from the recovery catalog.

• Print a stored script to the message log file or the screen.

• Obtain a listing of all your stored scripts.

To create a stored script:

1. Start RMAN and connect to the recovery catalog database. For example, enter:

   % rman catalog rman/rman@rcat
   

2. Write the desired script. For example, this script backs up the database and the archived redo logs:

   create script b_whole{
        allocate channel ch1 type disk;
        allocate channel ch2 type disk;
        backup database;
        sql 'ALTER SYSTEM ARCHIVE LOG ALL';
        backup archivelog all;
   }
   

3. Examine the output. If you see message RMAN-08085, then the script was successfully created and stored in the recovery catalog:

   RMAN-03022: compiling command: create script
   RMAN-03023: executing command: create script
   RMAN-08085: created script b_whole
   

To execute a stored script:

1. Start RMAN and connect to the recovery catalog database and target database. For example, enter:

   % rman target / catalog rman/rman@rcat
   

2. Issue a run command to execute the script. RMAN inserts the contents of the script between the brackets of run. Note that you do not need to allocate channels if you already did so within the script:

   run { execute script b_whole; }
   

   See Also: "run" for execute script command syntax.

To replace a stored script:

1. Start RMAN and connect to the recovery catalog database and target database. For example, enter:

   % rman target / catalog rman/rman@rcat
   

2. Issue a replace script command to replace a stored script with another. For example, this command replaces script b_whole with the following:

   replace script b_whole {
        allocate channel ch1 type 'sbt_tape';
        backup database;
   }
   

   See Also: "replaceScript" for replace script command syntax.

To delete a stored script:

1. Start RMAN and connect to the recovery catalog database. For example, enter:

   % rman catalog rman/rman@rcat
   

2. Issue a delete script command to delete the specified stored script:

   delete script 'b_whole';
   

   See Also: "deleteScript" for delete script command syntax.

To print a stored script to a message log:

1. Start RMAN and connect to the recovery catalog database and target database, specifying the log argument if you want to print to a message log. For example, enter the following to specify rman_log:

   % rman target / catalog rman/rman@rcat log rman_log
   

2. Issue a print script command to write the script to the log:

   print script b_whole;
   

3. Host out to the operating system and use a text editor to view the script. For example, enter:

   RMAN> host;
   % vi rman_log
   

   See Also: "printScript" for print script command syntax.

To obtain a listing of all stored scripts:

1. Start SQL*Plus and connect to the recovery catalog database. For example, to connect to database RCAT enter:

   % sqlplus rman/rman@rcat
   

2. Issue a SELECT statement on the RC_STORED_SCRIPT view:

   SQL> SELECT script_name FROM rc_stored_script;
   SCRIPT_NAME 
   --------------------------------------------------------------------------------
   backupdb 
   binc
   binc1
   3 rows selected.
   

   See Also: "RC_STORED_SCRIPT" for information about the RC_STORED_SCRIPT view.

Resynchronizing the Recovery Catalog

When RMAN performs a resynchronization, it compares the recovery catalog to either the current control file of the target database or a backup control file and updates it with information that is missing or changed.

Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed information, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments (only if the database is open), and online redo logs. In a full resynchronization, RMAN updates all changed records, including those for the database schema.

When resynchronizing, RMAN does the following:

1. Creates a snapshot control file.

2. Compares the recovery catalog to the snapshot.

3. Updates the catalog with information that is missing or changed.

RMAN performs partial or full resynchronizations automatically as needed when you execute certain commands (see "resync" for more information). To ensure a full resynchronization, issue a resync catalog command.

This section contains the following topics:

• What Is Resynchronized?

• When Should You Resynchronize?

• How Do You Resynchronize?

What Is Resynchronized?

Table 3-3 describes the types of records that RMAN resynchronizes.

Table 3-3 Records Updated during a Resynchronization

When Should You Resynchronize?

RMAN automatically performs full or partial resynchronizations as needed in certain situations. Execution of the following commands performs a full or partial resynchronization (depending on whether the schema metadata has changed) automatically when the target database control file is mounted and the recovery catalog database is available when the command is executed:

• backup

• copy

• crosscheck

• delete expired backupset

• duplicate

• list

• recover

• report

• restore

• switch

For example, if you execute a backup command you see partial resynchronization messages after the backup completes:

RMAN-08525: backup set complete, elapsed time: 00:00:02
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: c1

Perform manual resynchronizations in the following scenarios.

Resynchronizing when the Recovery Catalog is Unavailable

If the recovery catalog is unavailable when you issue backup or copy commands, then open the catalog database later and resynchronize it manually using the resync catalog command.

Resynchronizing when You Run in ARCHIVELOG Mode

If you are running in ARCHIVELOG mode, resynchronize the recovery catalog regularly because the recovery catalog is not updated automatically when a redo log switch occurs or when a redo log is archived. Instead, Oracle stores information about log switches and archived redo logs in the control file. You must propagate this information periodically into the recovery catalog.

How frequently you resynchronize the recovery catalog depends on the rate at which Oracle archives redo logs. The cost of the operation is proportional to the number of records in the control file that have been inserted or changed since the previous resynchronization. If no records have been inserted or changed, then the cost of resynchronization is very low. Thus, you can perform this operation frequently--for example, hourly--without incurring undue costs.

Resynchronizing After Physical Database Changes

Resynchronize the recovery catalog after making any change to the physical structure of the target database. As with redo log archive operations, the recovery catalog is not updated automatically when a physical schema change is made.

A physical schema change occurs when you:

• Add or drop a tablespace.

• Add a new datafile to an existing tablespace.

• Add or drop a rollback segment.

When resynchronizing from the current control file, RMAN automatically detects the records in the control file that have been updated and resynchronizes only those records. If the target database is open, then RMAN also updates information about rollback segments in the recovery catalog (this information is used for TSPITR).

When resynchronizing from a backup control file, RMAN does not verify that the backup pieces or file copies actually exist. Thus, you may need to use the change ... crosscheck and crosscheck commands to remove records for files that no longer exist.

How Do You Resynchronize?

Issue the resync catalog command to force a full resynchronization of the recovery catalog.

To perform a full resynchronization of the recovery catalog:

1. Open the recovery catalog database (if it is not already open). For example, enter:

   SQL> STARTUP pfile=initRCAT.ora
   
   

2. Use RMAN to connect to the target and recovery catalog databases. For example, enter:

   % rman target sys/change_on_install@prod1 catalog rman/rman@rcat
   
   

3. Mount the target database if it is not already mounted:

   startup mount;
   

4. Issue the resync catalog command:

   resync catalog;
   

   
   
   RMAN-03022: compiling command: resync
   RMAN-03023: executing command: resync
   RMAN-08002: starting full resync of recovery catalog
   RMAN-08004: full resync complete
   
   

   See Also: "resync" for resync catalog command syntax.

   Managing Records in the Control File

   The recovery catalog is dependent on the target database control file for information. Consequently, the currency of the information in the control file determines the effectiveness of the recovery catalog.

   The size of the target database's control file grows depending on the number of:

   • Backups that you perform.

   • Archived redo logs that Oracle generates.

   • Days that this information is stored in the control file.

   You can use the CONTROL_FILE_RECORD_KEEP_TIME parameter to specify the minimum number of days that Oracle keeps this information in the control file. Entries older than the number of days specified are candidates for overwrites by newer information. The larger the CONTROL_FILE_RECORD_KEEP_TIME setting, the larger the control file.

   At a minimum, resynchronize your recovery catalog at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting, because after the number of days specified in this parameter, Oracle overwrites the information in the control file with the most recently created information. If you have not resynchronized the recovery catalog, and Oracle has overwritten the information, then this information cannot be propagated to the recovery catalog.

   Note: The maximum size of the control file is port-specific. See your operating system-specific Oracle documentation.

   See Also: Oracle8i Reference for more information about the CONTROL_FILE_RECORD_KEEP_TIME parameter Oracle8i Backup and Recovery Guide for more information about managing control files for backup and recovery Oracle8i Administrator's Guide for more detailed information on all aspects of control file management

   Cataloging Operating System Backups

   You can make RMAN aware of the existence of file copies that are created through means other than RMAN. This section contains the following topics:

   • What Is Cataloging?

   • When Should You Catalog an Operating System Backup?

   • How Do You Catalog an Operating System Backup?

   What Is Cataloging?

   If you do not make backups or image copies by using RMAN commands, then the recovery catalog has no record of them. You must manually notify RMAN when you make backups with an operating system utility. Use the RMAN catalog command to:

   • Add information about an operating system datafile copy, archived redo log copy, or control file copy to the recovery catalog and control file.

   • Catalog a datafile copy as a level 0 backup, thus enabling you to perform an incremental backup later using the datafile copy as the base of an incremental backup strategy.

   • Record the existence of backups of version 8 databases created before RMAN was installed.

   • Record the existence of Oracle7 backups of read-only or offline normal files made before migrating to Oracle8i.

   When Should You Catalog an Operating System Backup?

   Catalog backups whenever:

   • You make a copy through an operating system utility.

   • You want to catalog Oracle7 operating system backups that were made offline normal or read-only prior to migration.

     Note: You cannot re-catalog backup sets or pieces.

   Cataloging Hot and Cold Operating System Backups

   Whenever you make a cold operating system backup, for example, by using the UNIX cp command to copy a datafile, make sure to catalog it. Oracle8i supports the ALTER TABLESPACE ... BEGIN/END BACKUP command, which allows open database operating system backups. Although RMAN does not create such backups, you can add them to the recovery catalog so that RMAN is aware of them.

   For a backup to be cataloged, it must be:

   • Accessible on disk.

   • A complete image copy of a single file.

   • Either a consistent or inconsistent whole database, tablespace, datafile, control file, or archived redo log backup. RMAN treats all such backups as datafile copies.

   For example, if you store datafiles on mirrored disk drives, you can create an operating system copy by breaking the mirror. In this scenario, use the catalog command to notify RMAN of the existence of the operating system copy after breaking the mirror. Before reforming the mirror, issue a change ... uncatalog command to notify RMAN that the file copy is being deleted.

   Cataloging Oracle7 Operating System Backups

   RMAN cannot catalog Oracle7 files, except in the following special circumstances. During the migration from Oracle7 to Oracle8i, you shut down your Oracle7 database cleanly prior to running the migration utility. At this time, you can take operating system backups of your Oracle7 datafiles and catalog the backups with RMAN: Oracle accepts them because no redo from the old database is required to recover them. RMAN can then restore those backups in your Oracle8i database if no other backups exist.

   Following is a scenario that generates an Oracle7 backup that you can catalog with RMAN:

   1. Take a datafile offline clean or read-only.

   2. Close the database. You must not have made the files read-write again before closing the database.

   3. Make an operating system backup of the offline or read-only files.

   4. Migrate the database to Oracle8i.

   The pre-migration backups are identical to the backups that would be taken prior to migration, and may also be cataloged with RMAN.

   See Also: Oracle8i Migration to learn how to migrate an Oracle database.

   How Do You Catalog an Operating System Backup?

   Use the catalog command to propagate information about operating system backups to the recovery catalog.

   To catalog an operating system backup:

   1. Make a backup via an operating system utility. This example backs up a datafile.

      % cp $ORACLE_HOME/dbs/sales.f $ORACLE_HOME/backup/sales.bak';
      

   2. Use RMAN to connect to the target and recovery catalog databases. For example, enter:

      % rman target change_on_install@prod1 catalog rman/rman@rcat
      

   3. Issue the catalog command. For example, enter:

      catalog datafilecopy '$ORACLE_HOME/backup/sales.bak';
      
      RMAN-03022: compiling command: catalog
      RMAN-03023: executing command: catalog
      RMAN-08050: cataloged datafile copy
      RMAN-08513: datafile copy filename=/oracle/backup/sales.bak recid=121 stamp=342972501
      RMAN-03023: executing command: partial resync
      RMAN-08003: starting partial resync of recovery catalog
      RMAN-08005: partial resync complete
      

      See Also: "catalog" for catalog command syntax.

   Backing Up and Recovering the Recovery Catalog

   Include the recovery catalog in your backup and recovery strategy. If you do not back up your recover catalog and a disk crash occurs, you may lose some or all of your data. Avoid this unpleasant scenario by deciding how to back up and recover the recovery catalog.

   This section contains the following topics:

   • Backing Up the Recovery Catalog

   • Recovering the Recovery Catalog

   • Re-Creating the Recovery Catalog

   Backing Up the Recovery Catalog

   When developing a strategy for backing up the recovery catalog, follow these guidelines:

   • Make Regular Backups

   • Use the Appropriate Method for Physical Backups

   • Store the Recovery Catalog in an Appropriate Place

   • Make Logical Backups

   Make Regular Backups

   Back up the recovery catalog with the same frequency that you back up your target database. For example, if you make a weekly whole database backup of your target database, then back up your recovery catalog immediately after each target database backup. The backed up catalog will have a record of the target backup preceding it, so if you are forced to restore the catalog you will also be able to use it to restore the target database backup.

   Use the Appropriate Method for Physical Backups

   When backing up the recovery catalog, you have a choice of making operating system or RMAN backups. The advantage of making operating system backups is that you can restore them using operating system methods without relying on RMAN or a recovery catalog. For operating system backup procedures, see Oracle8i Backup and Recovery Guide.

   If you use RMAN to back up the recovery catalog database, consider how you will restore the recovery catalog in case of failure. For example, you can:

   • Back up the recovery catalog database using RMAN, but start RMAN with the nocatalog option so that the backup repository for the recovery catalog is the control file in the catalog database. Make frequent backups of this control file using SQL. Remember to set the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter to a value that is high enough to store an adequate amount of historical backup data for the catalog.

   Figure 3-1 Using the Control File as the Repository for Backups of the Catalog

   
   
   • Create a second recovery catalog in a separate database. The main catalog is kept synchronized as normal, while the secondary catalog is synchronized manually by periodically issuing the resync catalog command. To learn how to create a catalog, see "Creating the Recovery Catalog".

   Figure 3-2 Registering One Database in Two Catalogs

   
   

   See Also: Oracle8i Backup and Recovery Guide to learn how to back up the control file using SQL statements.

   Store the Recovery Catalog in an Appropriate Place

   Never store a recovery catalog containing the RMAN repository for a database in the same database as your target database. For example, do not store the catalog for database PROD1 in PROD1. A recovery catalog for PROD1 is only effective if it is separated from the data that it is designed to protect. If PROD1 suffers a total media failure, and the recovery catalog data for PROD1 is also stored in PROD1, then you have no catalog to aid in recovery.

   This rule is especially important when you want to back up a recovery catalog database. Take a case in which database RCAT contains the recovery catalog repository for target database PROD1. You decide to use a recovery catalog to back up RCAT, but are not sure where to store this catalog. If you store the catalog containing the repository for RCAT in database RCAT itself, then if you lose RCAT because of a media failure you will have difficulty restoring RCAT and will leave PROD1 unprotected.

   Make Logical Backups

   Use the Export utility to make convenient backups of your recovery catalog data. An export of the catalog allows the most flexibility when the recovery catalog must be restored, because it can be restored to any existing Oracle8i database.

   To make a logical export of the recovery catalog from the command line:

   1. Execute the export operation at the command line, making sure to do the following:
      1. Connect as the owner of the recovery catalog.

      2. Specify the OWNER option.

      3. Specify an output file.

      For example, if the owner of the catalog in database PROD1 is RMAN, you can issue the following at the UNIX command line to export the catalog to file cat.dmp:

      % exp rman/rman@prod1 file=cat.dmp owner=rman
      

   2. Examine the output to make sure you were successful:

      Export terminated successfully without warnings.
      

      See Also: Oracle8i Utilities to learn how to use the Export utility, and Oracle8i Backup and Recovery Guide to learn how to make operating system backups.

   Recovering the Recovery Catalog

   The method you use to recover the catalog depends on the method you use to back it up. You have these options:

   • Recovering the Catalog Using Operating System Methods

   • Recovering the Catalog Using RMAN

   • Importing a Logical Backup of the Catalog

   Recovering the Catalog Using Operating System Methods

   If you backed up the recovery catalog using operating system commands, then restore the backup of the catalog using operating system commands and issue SQL*Plus commands to recover it. The method you use depends on whether you are recovering the entire recovery catalog database or only the tablespace in which the recovery catalog is stored. For procedures, see Oracle8i Backup and Recovery Guide.

   Recovering the Catalog Using RMAN

   If you use RMAN to recover the catalog, then see Chapter 6, "Restoring and Recovering with Recovery Manager" for the relevant procedures.

   Importing a Logical Backup of the Catalog

   If you used Export to make a logical backup of the recovery catalog, then use Import to recover it. If a media failure damages your recovery catalog database, do the following:

   1. Create a new user in another database. For the recommended SQL syntax for creating a new user in a recovery catalog database, see "Creating the Recovery Catalog".

   2. Import the catalog data from the Export file. Execute the import at the command line, making sure to do the following:
      1. Connect as the new owner of the recovery catalog.

      2. Specify the old owner using the FROMUSER parameter.

      3. Specify the new owner using the TOUSER parameter.

      4. Specify the import file.

      For example, assume the following:

      • The old owner of the catalog in database PROD1 is RMAN.

      • The user in the new recovery catalog database NEW_CAT is RCAT.

      • The file containing the export of the catalog is cat.dmp.

        % imp userid=rcat/rcat_pwd@new_cat file=cat.dmp fromuser=rman touser=rcat 
        

   3. Use the imported catalog data for restore and recovery of your target database.

      See Also: Oracle8i Utilities to learn how to use the Import utility.

   Re-Creating the Recovery Catalog

   If the recovery catalog database is lost or damaged, and recovery of the recovery catalog database through the normal Oracle recovery mechanisms is not possible, then you must re-create the catalog.

   You have two options for partially re-creating the contents of the old catalog:

   • Issue catalog commands to re-catalog archived redo logs, backup control files, and datafile copies.

   • Use the resync catalog from controlfilecopy command to extract information from a backup control file and rebuild the recovery catalog from it.

   You can re-create information about backup sets only by using the resync catalog from controlfilecopy command, because the catalog command does not support re-cataloging of backup pieces or backup sets. RMAN does not verify that the files being re-cataloged still exist, so the resynchronization may add records for files that no longer exist. Remove such records by issuing change ... crosscheck or crosscheck backup commands.

   See Also: "change" for information about the change command, and "crosscheck" for information about the crosscheck command.

   Upgrading the Recovery Catalog

   If you use a version of the recovery catalog that is older than that required by the RMAN executable, then you must upgrade it. For example, you must upgrade the catalog if you use an 8.1 version of RMAN with an 8.0 recovery catalog.

   You receive an error when issuing upgrade catalog if the recovery catalog is already at a version greater than that required by the RMAN executable. RMAN permits the upgrade catalog command to be run if the recovery catalog is current and does not require upgrading, however, so that you can re-create packages at any time if necessary. Check the message log for error messages generated during the upgrade.

   To upgrade the recovery catalog:

   1. Use RMAN to connect to the target and recovery catalog databases. For example, enter:

      % rman target / catalog rman/rman@rcat
      

      
      
      RMAN-06008: connected to recovery catalog database 
      RMAN-06186: PL/SQL package rcat.DBMS_RCVCAT version 08.00.04 in RCVCAT 
                  database is too old
      
      
      

   2. Issue the upgrade catalog command:

      RMAN> upgrade catalog
      

      
      
      RMAN-06435: recovery catalog owner is rman 
      RMAN-06442: enter UPGRADE CATALOG command again to confirm catalog upgrade 
      
      
      

   3. Enter the update catalog command again to confirm:

      RMAN> upgrade catalog
      

      
      
      RMAN-06408: recovery catalog upgraded to version 08.01.05
      RMAN-06452: DBMS_RCVMAN package upgraded to version 08.01.05
      RMAN-06452: DBMS_RCVCAT package upgraded to version 08.01.03
      
      

      See Also: "upgradeCatalog" for upgrade catalog command syntax "configure" for information about recovery catalog compatibility Oracle8i Migration for complete compatibility and migration information

   Dropping the Recovery Catalog

   If you do not want to maintain a recovery catalog, then you can drop the recovery catalog schema from the tablespace. The drop catalog command deletes all information from the recovery catalog. Hence, if you have no backups of the recovery catalog schema, then all backups of all target databases managed by this catalog become unusable.

   The drop catalog command is not appropriate for "unregistering" a single database from a catalog that registers multiple target databases. If you try to delete the information for one target database by dropping the catalog, you delete the information for all target databases.

   To drop the recovery catalog schema:

   1. Use RMAN to connect to the target and recovery catalog databases.

      % rman target / catalog rman/rman@rcat
      

   2. Issue the drop catalog command twice to confirm:

      RMAN> drop catalog
      

      
      
      RMAN-06435: recovery catalog owner is rman
      RMAN-06436: enter DROP CATALOG command again to confirm catalog removal
      RMAN> drop catalog
      
      

      Note: Even after you drop the recovery catalog, the control file still contains records about your backups. To purge those records, re-create the control file.

      See Also: "dropCatalog" for drop catalog command syntax, and "Unregistering a Database from the Recovery Catalog" to learn how to unregister a database from the catalog.

   Managing the RMAN Repository Without a Recovery Catalog

   RMAN works perfectly well without a recovery catalog. In fact, the recovery catalog receives its information from the control file. If you choose not to use a recovery catalog, however, you must perform the following tasks:

   • Understanding Catalog-Only Command Restrictions

   • Monitoring the Overwriting of Control File Records

   • Maintaining the Control File Repository

   • Backing Up the Control File

     See Also: Oracle8i Concepts for a conceptual overview of the control file. Chapter 3, "Managing the Recovery Manager Repository" for a description of the importance of the control file for backup and recovery Oracle8i Administrator's Guide for more detailed information on managing the control file

   Understanding Catalog-Only Command Restrictions

   If you choose not to use a recovery catalog, you can still use RMAN very effectively. RMAN obtains the information it needs from the control file of the target database. Nevertheless, some commands are not available when you use the control file as the sole repository of RMAN metadata. The following commands are only available when you use a recovery catalog:

   • change ... available, change ... unavailable, change ... uncatalog, change backupset ... crosscheck, change backuppiece ... crosscheck

   • configure compatible

   • create catalog, upgrade catalog, drop catalog

   • create script, delete script, replace script, print script

   • crosscheck backup

   • delete expired backup

   • list incarnation

   • register database

   • report schema at time

   • reset database

   • restore (when no control file is available)

   • resync catalog

   • set auxname

   To restore and recover your database without using a recovery catalog, Oracle recommends that you:

   • Use a minimum of three multiplexed or mirrored control files, with each control file on a separate disk.

   • Keep excellent records of which files were backed up, the date they were backed up, and also the names of the backup pieces each file was written to. Use the list command to obtain information about backups and copies. Keep all RMAN backup logs.

     WARNING: The only way to restore and recover when you have lost all control files and do not use a recovery catalog is to call Oracle Support Services. Support will need to know the following: Current schema of the database Which files were backed up What time the files were backed up Names of the backup pieces containing the files

   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 and copies. As you make backups and copies, Oracle adds new records to the control file. These records are circularly reused, which means that Oracle overwrites older records.

   See Also: "Types of Records in the Control File" for a conceptual overview of control file records.

   The following 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. Any information in an overwritten record is lost.

   Note: If you maintain a recovery catalog, use the RMAN resync catalog command to resynchronize the catalog before records are reused. In this way, RMAN never loses records because they are recorded in the recovery catalog.

   What happens when Oracle needs to add new records to the control file, but the oldest record is less than the value specified in CONTROL_FILE_RECORD_KEEP_TIME? The following steps occur:

   1. Oracle attempts to expand the size of the control file, which it can only do if the underlying operating system file can be expanded.

   2. If it cannot expand the control file, then Oracle overwrites the oldest record--regardless of whether its age is less than the CONTROL_FILE_RECORD_KEEP_TIME value--and logs this action in the alert.log.

   Assume the following scenario:

   • You do not use a recovery catalog.

   • CONTROL_FILE_RECORD_KEEP_TIME is set to 14.

   • All records currently in the control file are between 1 and 13 days old.

   • The control file is at the maximum size permitted by your operating system.

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

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

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

   • Store the control file in a file system rather than raw disk so that it can expand as needed.

   • Monitor the alert.log to make sure that Oracle is not overwriting control file records.

   Maintaining the Control File Repository

   RMAN provides several commands that allow you to check and delete records of backups as well as physically remove backups and copies. "Maintaining the RMAN Repository" provides a complete description of these maintenance procedures. Most of these commands work whether or not you use a recovery catalog.

   For a list of the commands that require a catalog, see "Connecting to RMAN". You do not lose much in the way of maintenance functionality when you do not use a recovery catalog, because you can:

   • Use the restore ... validate or validate backupset commands to test whether backups and copies are available and can be restored. See "Validating the Restore of Backups and Copies" for a description of this procedure.

   • Use change ... delete to mark records as DELETED in the control file and physically delete unwanted or corrupted backups and copies from the operating system. See "Deleting Backups and Copies and Updating Their Status in the RMAN Repository" for a description of this procedure.

   Backing Up the Control File

   If you use the control file as the sole repository of the RMAN metadata, maintain alternate control files through multiplexing or operating system mirroring and back up the control file frequently. If you lose your control file and do not have a backup, you lose all information about RMAN backups and copies contained in the file.

   To learn how to multiplex and mirror the control file and to make operating system backups of the control file, see Oracle8i Backup and Recovery Guide.