6
Managing Recovery Manager Metadata

This chapter describes how to manage the RMAN metadata. Depending on how you implement RMAN, you can store this data either in the recovery catalog or exclusively in the control file. The chapter includes the following topics:

Creating the Recovery Catalog

To use a recovery catalog, you need to set up the schema. Oracle suggests you put the recovery catalog schema in its own tablespace; however, you can put it in the SYSTEM tablespace if necessary.

Install the recovery catalog schema in a different database from the target database you will be backing up. If you do not, the benefits of using a recovery catalog are lost should you lose the database and need to restore.

WARNING:
Ensure that the recovery catalog and target databases do not reside on the same disks; if they do and you lose one database, you will probably lose the other.

Assume the following for the examples below:

User SYS with password CHANGE_ON_INSTALL has SYSDBA privileges on the recovery catalog database RCAT.
There is a tablespace called RCVCAT on the recovery catalog database RCAT that stores the recovery catalog.
There is a tablespace called TEMP in the recovery catalog database.
The database is configured in the same way as all normal databases, e.g., catalog.sql and catproc.sql have successfully run.

See Also: To learn how to connect to RMAN, see "Connecting to RMAN". To learn about the advantages and disadvantages of maintaining a recovery catalog, see "Deciding Whether to Use a Recovery Catalog".

To set up the recovery catalog schema:

Start SQL*Plus and then connect with administrator privileges to the database containing the recovery catalog. For example, enter:
```
SQL> CONNECT sys/change_on_install@rcat
    

         
```
Create a log file that you can use to check for errors. For example, enter:
```
SQL> SPOOL create_rman.log
    

         
```

Create a user and schema for the recovery catalog. For example, enter:

SQL> CREATE USER rman IDENTIFIED BY rman
2> TEMPORARY TABLESPACE temp 
3> DEFAULT TABLESPACE rcvcat 
4> QUOTA UNLIMITED ON rcvcat;

Grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user with privileges to maintain and query the recovery catalog.
```
SQL> GRANT recovery_catalog_owner TO rman;
    

         
```

Grant other desired privileges to the RMAN user.

SQL> GRANT connect, resource TO rman;

Host out to the operating system to check the create_rman.log file for any errors before continuing. For example, a UNIX user can issue:
```
SQL> host
% vi create_rman.log
```

To create the recovery catalog:

Connect to the recovery catalog from the O/S command line. For example, enter:

% rman catalog rman/rman@rcat log = create_rman.log

You can also connect from the RMAN prompt:

% rman log = create_rman.log
RMAN> connect catalog rman/rman@rcat

Issue the create catalog command to create the catalog, specifying the RCVCAT tablespace:
```
RMAN> create catalog tablespace rcvcat;
    

         
```
Host out to the operating system to check the create_rman.log file for any errors before continuing. For example, a UNIX user might issue:
```
RMAN> host;
% vi create_rman.log
```

See Also: For create catalog command syntax, see "createCatalog". For the SQL syntax for the GRANT and CREATE USER statements, see the Oracle8i SQL Reference.

Maintaining RMAN Metadata

This section describes how to manage the RMAN information repository. It assumes that you are using a recovery catalog. If you use a control file as the exclusive repository for RMAN metadata, most RMAN maintenance commands will work. See "Consequences of Using the Control File for RMAN Metadata" for a list of catalog-only commands.

This section includes the following topics:

Registering a Database with the Recovery Catalog

Before using RMAN with a target database, register the target database in the recovery catalog. If you do not, RMAN cannot use the recovery catalog to store information about the target database. RMAN obtains all information it needs to register the target database from the database itself. You can register more than one target database in the same recovery catalog.

Note:
You can only register a database once.

To register the target database:

Connect to the target database and recovery catalog. For example, issue the following to connect to the catalog database RCAT as RMAN:
```
% rman target / catalog rman/rman@rcat 
    

         
```
If the database is not mounted, then mount or open it. For example, issue:
```
startup mount;
    

         
```
If you are creating a new database or migrating an existing Oracle7 database, or if RMAN is installed for use with an existing version 8.0 or higher database, issue the following command:
```
register database;
    

         
```
If there are any existing user-created backups on disk that were created under version 8.0 or higher, add them to the recovery catalog by issuing the following command:
```
catalog datafilecopy 'filename';
    

         
```
For an Oracle7 backup to be usable for recovery in database of a later version, it must have been part of a tablespace that was offline normal or read-only when the database was migrated. See "Cataloging O/S Backups".

Note:
Backups made with the Enterprise Backup Manager (EBU) cannot be used or cataloged by RMAN.
RMAN automatically obtains information about the original archived redo logs from the target database control file. If you have made additional O/S backups of your archived logs, or if log records have aged out of the target control file, catalog them. For example, you can catalog logs as follows (where log1 etc. refers to the fully specified filename for an archived log):
```
catalog archivelog 'log1', 'log2', 'log3', ... 'logN';
```
Note:
To determine whether log records have aged out of the control file, compare the number of logs on disk with the number of records in V$ARCHIVED_LOG.

Oracle uses an internal, uniquely generated number called the db identifier to distinguish one database from another. Oracle generates this number when you create the database.

Typically, each database has a unique identifier; however, an exception occurs with databases that you create by copying files from an existing database (instead of using a CREATE DATABASE statement). In such cases, RMAN detects the duplicate database identifiers and the register database command fails. Avoid this problem by using the duplicate command, which copies the database from backups and generates a new database identifier.

If a failure occurs because of duplicate database identifiers, you can create a second recovery catalog in another user's schema by re-executing the create catalog command using a different Oracle userid. Then, you can register the database with a duplicate database identifier into the newly created recovery catalog in the new schema.

Note:
If you are using RMAN with different target databases that have the same database name and identifier, be extremely careful to always specify the correct recovery catalog schema when invoking Recovery Manager.

See Also: For register command syntax, see "register". For catalog command syntax, see "catalog". For duplicate command syntax, see "duplicate". For issues relating to database migration, see Oracle8i Migration.

Unregistering a Database from the Recovery Catalog

RMAN allows you to unregister a database as well as register it. Make sure this procedure is really what you intend, because afterwards RMAN can longer recover all the backups for that database.

To unregister a database:

Start RMAN and connect to your target database. Note down the DBID value that is displayed when you use RMAN to connect to your target database. For example, enter:

% rman target sys/change_on_install@prod1 nocatalog
    

    RMAN-06005: connected to target database: RMAN (DBID=1231209694)

List the copies and backup sets recorded in the control file and then issue change ... delete statements to delete them from the O/S. See "Generating Lists" and "Deleting Backups and Copies and Updating Their Status in the RMAN Metadata".
Use SQL*Plus to connect to your recovery catalog database and execute the following query in the recovery catalog to find the correct row of the DB table, setting DB_ID equal to the value you obtained from step 1. For example, enter:
```
SQL> SELECT db_key, db_id FROM db WHERE db_id = 1231209694;
    

         
```
This query should return exactly one row.
```
DB_KEY     DB_ID      
---------- ----------
         1 1237603294 
1 row selected.
    

         
```
While still connected to the recovery catalog, enter the following, where DB_KEY and DB_ID are the corresponding columns from the row you got from the query in step 2:
```
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(db_key, db_id)
    

         
```
For example, enter:
```
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(1 , 1237603294)
```
Note:
The DBMS_RCVCAT.UNREGISTERDATABASE package works on any Oracle version 8 database.

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 command but do not reset the database, then RMAN will not 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 some 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:

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

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

reset database to incarnation 2;

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;
     sql "ALTER DATABASE OPEN RESETLOGS";
}
    

         
```

See Also: For reset database command syntax, see "reset". For list command syntax, see "list".

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 will not be 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.

Note:
You must use a recovery catalog when executing change ... unavailable and change ... available.

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

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;

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: For change command syntax, see "change".

Crosschecking RMAN Metadata

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 O/S files or remove metadata 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

Yes

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.

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	Yes	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.

See Also: To learn how to delete files and update metadata records, see "Deleting Backups and Copies and Updating Their Status in the RMAN Metadata". For crosscheck command syntax, see "crosscheck".

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.

Note:
The change command operates only on files that are recorded in the recovery catalog or the control file. The same is true for other commands except catalog and resync from controlfilecopy.

To provide a list of backups for a crosscheck:

Allocate a channel of type maintenance:

allocate channel for maintenance type 'sbt_tape';

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

         
```

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.

Release the allocated maintenance channel:
```
release channel;
```

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

Allocate a channel of type maintenance:

allocate channel for maintenance type 'sbt_tape';

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.
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. Query the relevant recovery catalog view to see copies and logs with deleted status.

Note that 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 will mark the absent logs as deleted. You do not need to use a recovery catalog to execute this command.

To crosscheck image copies:

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
```

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

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 metadata after archived redo logs have been removed:

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

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

Issue a change ... crosscheck command to update the metadata records for the absent archived redo logs. This example crosschecks all archived redo logs:
```
change archivelog all crosscheck;
    

         
```

See Also: For crosscheck command syntax, see "crosscheck". For change command syntax, see "change". For list command syntax, see "list".

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

You can use RMAN to delete backups and copies and update their status in the control file or recovery catalog to deleted status. Note that backup and copies with deleted status do not appear in the list command output: query the recovery catalog views instead.

Following are typical scenarios:

Command or Script Need Catalog? Purpose

change ... uncatalog

Yes

To remove the record of a specified backup or copy from the recovery catalog. This command does not delete physical backups or copies: it only removes their records.
Note: If you resynchronize from a backup control file, the removed records can reappear in the catalog.

prgrmanc.sql

Yes

To remove all records of backups or copies with status deleted from the catalog at one time. The script does not delete physical backups or copies: it only removes their records.
Note: If you resynchronize from a backup control file, the removed records can reappear in the catalog.

delete expired backup

Yes

To update backup sets records from status expired to status deleted. RMAN also physically deletes any expired backups if they still exist.
Typically, you issue this command after performing a crosscheck. A crosscheck marks inaccessible backups as expired.

change ... delete

No

To delete physical backup sets, image copies, or archived redo logs and update their metadata records to status deleted.
Unlike the delete expired command, change ... delete operates on any backup or copy--not just those marked expired.

Command or Script	Need Catalog?	Purpose
change ... uncatalog	Yes	To remove the record of a specified backup or copy from the recovery catalog. This command does not delete physical backups or copies: it only removes their records. Note: If you resynchronize from a backup control file, the removed records can reappear in the catalog.
`prgrmanc.sql`	Yes	To remove all records of backups or copies with status deleted from the catalog at one time. The script does not delete physical backups or copies: it only removes their records. Note: If you resynchronize from a backup control file, the removed records can reappear in the catalog.
delete expired backup	Yes	To update backup sets records from status expired to status deleted. RMAN also physically deletes any expired backups if they still exist. Typically, you issue this command after performing a crosscheck. A crosscheck marks inaccessible backups as expired.
change ... delete	No	To delete physical backup sets, image copies, or archived redo logs and update their metadata records to status deleted. Unlike the delete expired command, change ... delete operates on any backup or copy--not just those marked expired.

See Also: For change command syntax, see "change". For delete command syntax, see "deleteExpired". For descriptions of the recovery catalog views, see Chapter 12, "Recovery Catalog Views".

To update the recovery catalog record for a backup or copy deleted with an O/S utility:

Allocate a channel of type maintenance:

allocate channel for maintenance type disk;

Issue a change ... uncatalog command for the backups or copies that you deleted from the operating system using O/S commands. This example removes references to copies of the control file and datafile 1:
```
change controlfilecopy '/oracle/backup/cf_c.f' uncatalog;
change datafilecopy '/oracle/backup/df_1_c.f' uncatalog;
    

         
```
Release the allocated channel:
```
release channel;
```

To physically delete backups and copies and update their metadata records:

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

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;

Allocate a channel of type delete:

allocate channel for delete type 'sbt_tape';

Issue a change ... delete command to eliminate both the physical file and change the recovery catalog record to status deleted. This example deletes the backup piece with key 101 and the control file copy with key 63 from tape:
```
change backuppiece 101 delete;
change controlfilecopy 63 delete;
    

         
```
Release the allocated maintenance channel:
```
release channel;
```

To update expired backup records in the catalog to status deleted (and delete any existing expired backup pieces):

This procedure requires the use of a recovery catalog.

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

Allocate a channel of type delete:

allocate channel for delete type disk;

Issue a delete expired backup command to check for backups marked expired and update them to status deleted. This example updates all backups registered in the recovery catalog that are expired:
```
delete expired backup;
    

         
```
Release the allocated channel:
```
release channel;
```

To remove individual copy or backup records from the recovery catalog (without physically deleting the backups or copies):

Check for the expired image copies or backups. Use the list output to obtain their primary keys. For example, enter:
```
list copy;
    

         
```
Issue a change ... uncatalog command to remove references to the specified backups or copies from the recovery catalog. 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 O/S; it only removes recovery catalog records.
View the relevant recovery catalog view, e.g., 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 or backup records from the recovery catalog (without physically deleting the backups or copies):

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.

See Also: For change command syntax, see "change".

Allocate a channel of type maintenance:

allocate channel for maintenance type 'sbt_tape';

Issue change ... delete commands to update the desired records to deleted status and remove the file from the O/S 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;
    

         
```
Release the allocated maintenance channel:
```
release channel;
    

         
```
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
    

         
```
Run the script prgrmanc.sql script, which is stored in the $ORACLE_HOME/rdbms/admin directory:
```
SQL> @prgrmanc.sql
    

         
```
RMAN will remove all records with status deleted from the recovery catalog.

To remove incarnation records from the recovery catalog:

Allocate a channel of type maintenance:

allocate channel for maintenance type 'sbt_tape';

Issue change ... delete commands to update unwanted backup pieces, archived redo logs, and image copies to deleted status. 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;
    

         
```
Release the allocated maintenance channel:
```
release channel;
    

         
```
Start a SQL*Plus session and connect to the recovery catalog. This example connects to database RCAT as user RMAN:
```
% sqlplus rman/rman@rcat
    

         
```
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;
    
 
         
```
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: For more information about the RC_DATABASE_INCARNATION recovery catalog view, see "RC_DATABASE_INCARNATION".

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: For restore command syntax, see "restore". For validate command syntax, see "validate".

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

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;
    

         
```
Start RMAN and connect to the target database and optional recovery catalog database:
```
% rman target / catalog rman/rman@rcat
    

         
```
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;
    

         
```

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;
}

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:

Start RMAN and connect to the target database and optional recovery catalog database:
```
% rman target / catalog rman/rman@rcat
    

         
```

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

list backup of database archivelog all;

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;
}
    

         
```

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 for 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 O/S text file has the advantage that it is accessible to any DBA using RMAN, regardless of which machine RMAN is executed upon.

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:

Start RMAN and connect to the recovery catalog database. For example, enter:
```
% rman catalog rman/rman@rcat
    

         
```

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;
}

Examine the output. If you see message RMAN-08085, 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:

Start RMAN and connect to the recovery catalog database and target database. For example, enter:
```
% rman target / catalog rman/rman@rcat
    

         
```
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: For execute script command syntax, see "run".

To replace a stored script:

Start RMAN and connect to the recovery catalog database and target database. For example, enter:
```
% rman target / catalog rman/rman@rcat
    

         
```

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: For replace script command syntax, see "replaceScript".

To delete a stored script:

Start RMAN and connect to the recovery catalog database. For example, enter:
```
% rman catalog rman/rman@rcat
    

         
```
Issue a delete script command to delete the specified stored script:
```
delete script 'b_whole';
    

         
```

See Also: For delete script command syntax, see "deleteScript".

To print a stored script to a message log:

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
    

         
```
Issue a print script command to write the script to the log:
```
print script b_whole;
    

         
```
Host out to the O/S and use an O/S utility to view the script. For example, enter:
```
RMAN> host;
% vi rman_log
    

         
```

See Also: For replace script command syntax, see "printScript".

To obtain a listing of all stored scripts:

Start SQL*Plus and connect to the recovery catalog database. For example, to connect to database RCAT enter:
```
% sqlplus rman/rman@rcat
    

         
```

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: For information about the RC_STORED_SCRIPT view, see "RC_STORED_SCRIPT".

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.

Note:
Although RMAN performs partial resynchronizations when the control file is a backup, it will not perform full resynchronizations.

When resynchronizing, RMAN creates a snapshot control file, compares the recovery catalog to the snapshot, and 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?

Table 6-1 describes the types of records that RMAN resynchronizes.

Table 6-1 Records Updated during a Resynchronization

Records	Description
log history	created when a online redo log switch occurs.
archived redo logs	associated with archived logs that were created by archiving an online log, copying an existing archived redo log, or restoring an archived redo log backup set. RMAN tracks this information so that it knows which archived logs it should expect to find.
backup history	associated with backup sets, backup pieces, backup set members, and file copies. The resync catalog command updates these records when a backup or copy command is executed.
physical schema	associated with datafiles and tablespaces. If the target database is open, then rollback segment information is also updated. Physical schema information in the recovery catalog is updated only when the target has the current control file mounted. If the target database has mounted a backup control file, a freshly created control file, or a control file that is less current than a control file that was seen previously, then physical schema information in the recovery catalog is not updated. Physical schema information is also not updated when you use the resync catalog from controlfilecopy command.

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

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:

Open the recovery catalog database (if it is not already open). For example, enter:
```
SQL> STARTUP pfile=initRCAT.ora
```
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
```
Mount the target database if it is not already mounted:
```
startup mount;
    

         
```

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: For resync catalog command syntax, see "resync".

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 will overwrite 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 O/S-specific Oracle documentation.

See Also: For more information about the CONTROL_FILE_RECORD_KEEP_TIME parameter, see the Oracle8i Reference. For more information about managing control files for backup and recovery, see "Managing the Control File". For more detailed information on all aspects of control file management, see the Oracle8i Administrator's Guide.

Cataloging O/S Backups

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

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 O/S utility. Use the RMAN catalog command to:

Add information about an O/S 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 O/S Backup?

Catalog backups whenever:

You make a copy via an O/S utility.
You want to catalog Oracle7 O/S 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 O/S Backups

Whenever you make a cold O/S backup, e.g., 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 O/S 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 O/S 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 O/S 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 O/S 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:

Take a datafile offline clean or read-only.
Close the database. You must not have made the files read-write again before closing the database.
Make an O/S backup of the offline or read-only files.
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.

How Do You Catalog an O/S Backup?

Use the catalog command to propagate information about O/S backups to the recovery catalog.

To catalog an O/S backup:

Make a backup via an O/S utility. This example backs up a datafile.

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

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

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

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: For catalog command syntax, see "catalog".

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 thinking about how to back up and recover the recovery catalog.

This section contains the following topics:

Backing Up the Recovery Catalog

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

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 O/S or RMAN backups. The advantage of making O/S backups is that you can restore them using O/S methods without relying on RMAN or a recovery catalog. For O/S backup procedures, see Chapter 13, "Performing Operating System Backups".

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:

Create a second recovery catalog in a separate database, e.g., the production database you are backing up. To learn how to create a catalog, see "Creating the Recovery Catalog".
Use the recovery catalog control file as the RMAN metadata repository for the recovery catalog, and make frequent backups of the recovery catalog control file using the ALTER DATABASE BACKUP CONTROLFILE TO 'filename' statement. To learn how to back up the control file using O/S methods, see "Performing Control File Backups".

Store the Recovery Catalog in an Appropriate Place

Never store a recovery catalog containing the RMAN metadata 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 metadata 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 metadata 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:

Execute the export 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
    

         
```

Examine the output to make sure you were successful:

Export terminated successfully without warnings.

See Also: To learn how to use the Export utility, see Oracle8i Utilities. To learn how to make O/S backups, see Chapter 13, "Performing 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 O/S Methods

If you backed up the recovery catalog using operating system commands, then restore the backup of the catalog using O/S 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 Chapter 14, "Performing Operating System Recovery".

Recovering the Catalog Using RMAN

If you use RMAN to recover the catalog, then see Chapter 9, "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:

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".
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 
    

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

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

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.

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 will receive an error on 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:

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

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

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: For upgrade catalog command syntax, see "upgradeCatalog". For complete compatibility and migration information, see Oracle8i Migration.

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:

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

% rman catalog rman/rman@rcvcat

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: For drop catalog command syntax, see "dropCatalog".

Managing RMAN Metadata 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:

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

Maintaining the Control File Metadata

RMAN provides several commands that allow you to check and delete records of backups as well as physically remove backups and copies. "Maintaining RMAN Metadata" 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 "Consequences of Using the Control File for RMAN Metadata". 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 remove outdated records from the control file and physically delete unwanted or corrupted backups and copies from the O/S. See "Deleting Backups and Copies and Updating Their Status in the RMAN Metadata" 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 O/S mirroring and back up the control file frequently. If you should lose your control file and do not have a backup, you will lose all information about RMAN backups and copies contained in the file.

To learn how to multiplex and mirror the control file, see "Managing the Control File". To learn how to make O/S backups of the control file, see "Backing Up the Control File to a Physical File" and "Backing Up the Control File to a Trace File".

6 Managing Recovery Manager Metadata

Creating the Recovery Catalog

To set up the recovery catalog schema:

To create the recovery catalog:

Maintaining RMAN Metadata

Registering a Database with the Recovery Catalog

To register the target database:

Unregistering a Database from the Recovery Catalog

To unregister a database:

Resetting the Recovery Catalog

To reset the recovery catalog to an older incarnation:

Changing the Availability of a Backup or File Copy

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

Crosschecking RMAN Metadata

Crosschecking Backups

To provide a list of backups for a crosscheck:

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

Crosschecking Image Copies

To crosscheck image copies:

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

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

To update the recovery catalog record for a backup or copy deleted with an O/S utility:

To physically delete backups and copies and update their metadata records:

To update expired backup records in the catalog to status deleted (and delete any existing expired backup pieces):

To remove individual copy or backup records from the recovery catalog (without physically deleting the backups or copies):

To remove incarnation records from the recovery catalog:

Validating the Restore of Backups and Copies

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

To specify which backup sets to validate:

Storing Scripts in the Recovery Catalog

To create a stored script:

To execute a stored script:

To replace a stored script:

To delete a stored script:

To print a stored script to a message log:

To obtain a listing of all stored scripts:

Resynchronizing the Recovery Catalog

What Is Resynchronized?

Table 6-1 Records Updated during a Resynchronization

When Should You Resynchronize?

Resynchronizing when the Recovery Catalog is Unavailable

Resynchronizing when You Run in ARCHIVELOG Mode

Resynchronizing After Physical Database Changes

How Do You Resynchronize?

To perform a full resynchronization of the recovery catalog:

Managing Records in the Control File

Cataloging O/S Backups

What Is Cataloging?

When Should You Catalog an O/S Backup?

Cataloging Hot and Cold O/S Backups

Cataloging Oracle7 O/S Backups

How Do You Catalog an O/S Backup?

To catalog an O/S backup:

Backing Up and Recovering the Recovery Catalog

Backing Up the Recovery Catalog

Make Regular Backups

Use the Appropriate Method for Physical Backups

Store the Recovery Catalog in an Appropriate Place

Make Logical Backups

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

Recovering the Recovery Catalog

Recovering the Catalog Using O/S Methods

Recovering the Catalog Using RMAN

Importing a Logical Backup of the Catalog

Re-Creating the Recovery Catalog

Upgrading the Recovery Catalog

To upgrade the recovery catalog:

Dropping the Recovery Catalog

To drop the recovery catalog schema:

Managing RMAN Metadata Without a Recovery Catalog

Maintaining the Control File Metadata

Backing Up the Control File

6
Managing Recovery Manager Metadata