Re-create the Recovery Catalog

In this lesson, you will discover several ways to re-create or rebuild your recovery catalog. The recovery catalog is stored as a database and is susceptible to the same problems as any other database. You could lose the recovery catalog because of hardware or software problems.

These are the first steps in re-creating your recovery catalog:

1. Create a database to store the recovery catalog. For our examples, the recovery catalog is on local database orc1.
2. Create a schema to own the recovery catalog; in our examples, it will be rman.
3. Grant connect and resource privileges to rman.
4. Grant recovery_catalog_owner to rman.
5. Run the catrman.sql script as the user rman.

When this is complete, you will have two options.

One option to rebuild your recovery catalog is to issue a series of catalog commands to recatalog all your archived logs, control files, and data files.

The resync command is another option to consider when rebuilding your recovery catalog. In this case, you would issue the resync command to restore from a backup control file. The command might look like this:

resync catalog from backup controlfile 


"C:\backup\ctrlorc1.bak"

This will restore your catalog based on the information stored in this control file. Hence, the restore may not be complete if the control file does not reflect the last state of your database. During a resynchronization, you may add records for backup files that do not exist. You will need to check and use the change delete command to remove them. If you have a current export of the catalog owner, rman in this case, you can use import to restore this information. You would then run a resync command to synchronize the recovery catalog with your target database. If you are using backup sets, you can use only the resync command. The catalog command does not understand backup sets or backup pieces.
The following section discusses the re-creation of your Oracle recovery catalog.

A recovery catalog is a database schema used by RMAN to store metadata about one or more Oracle databases. Typically, you store the catalog in a dedicated database. A recovery catalog provides the following benefits:

1. A recovery catalog creates redundancy for the RMAN repository stored in the control file of each target database. The recovery catalog serves as a secondary metadata repository. If the target control file and all backups are lost, then the RMAN metadata still exists in the recovery catalog.
2. A recovery catalog centralizes metadata for all your target databases. Storing the metadata in a single place makes reporting and administration tasks easier to perform.
3. A recovery catalog can store metadata history much longer than the control file. This capability is useful if you have to do a recovery that goes further back in time than the history in the control file. The added complexity of managing a recovery catalog database can be offset by the convenience of having the extended backup history available.

Some RMAN features function only when you use a recovery catalog. For example, you can store RMAN scripts in a recovery catalog. The chief advantage of a stored script is that it is available to any RMAN client that can connect to the target database and recovery catalog. Command files are only available if the RMAN client has access to the file system on which they are stored. A recovery catalog is required when you use RMAN in a Data Guard environment. By storing backup metadata for all primary and standby databases, the catalog enables you to offload backup tasks to one standby database while enabling you to restore backups on other databases in the environment.
In the next lesson, you will learn how to use the report command to analyze a recovery catalog.