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 the recovery catalog with information that is missing or changed. When resynchronizing, RMAN does the following:

Creates a snapshot control file.
Compares the recovery catalog to the snapshot control file.
Updates the recovery catalog with missing or changed information.

RMAN performs resynchronizations automatically as needed when you execute certain commands, including BACKUP. You can also manually perform a full resynchronization using the RESYNC CATALOG command.

Types of Records Updated When Recovery Catalog is Resynchronized

Table 10-2, "Records Updated During a Resynchronization" describes the types of records that RMAN resynchronizes.

Table 10-2 Records Updated During a Resynchronization

Records	Description
Log history	Created when an 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, proxy copies, and file copies. The `RESYNC` `CATALOG` command updates these records when a `BACKUP` command is executed.
Incarnation history	Associated with database incarnations.
Physical schema	Associated with datafiles and tablespaces. If the target database is open, then undo 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.

Full and Partial Resynchronization

Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed information about new backups, new archived logs, and so forth. However, RMAN 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 using a backup control file, it does not perform full resynchronizations. A backup control file may not have correct information about the database physical schema, so a full resynchronization could update the recovery catalog with incorrect information.

Note:

You can use Oracle Enterprise Manager to perform catalog resynchronizations.

When to Resynchronize the Recovery Catalog

RMAN automatically performs full or partial resynchronizations in most situations in which they are needed. Most RMAN commands such as BACKUP, DELETE, and so forth perform 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. Thus, you should not need to manually run RESYNC CATALOG very often.

The following sections describe situations in which a manual resynchronization is required.

Resynchronizing After the Recovery Catalog is Unavailable

If the recovery catalog is unavailable when you issue RMAN commands that cause a partial resynchronization, then open the catalog database later and resynchronize it manually with the RESYNC CATALOG command.

For example, the target database may be in New York while the recovery catalog database is in Japan. You may not want to make daily backups of the target database in CATALOG mode, to avoid depending on the availability of a geographically distant database. In such a case you could connect to the catalog as often as feasible (for example, once each week) and run the RESYNC CATALOG command.

Resynchronizing in ARCHIVELOG Mode When You Back Up Infrequently

Assume that you do the following:

Run the database in ARCHIVELOG mode
Back up the database infrequently (for example, hundreds of archive logs are archived between database backups)
Generate a high number of log switches every day (for example, 1000 switches between catalog resynchronizations)

In this case, you may want to manually 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. The database stores information about log switches and archived redo logs only in the control file. You must periodically resynchronize in order to propagate this information into the recovery catalog.

How frequently you need to resynchronize the recovery catalog depends on the rate at which the database 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; if many records have been inserted or changed, then the resynchronization is more time-consuming.

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 after physical schema changes, such as adding or dropping tablespaces, adding datafiles to a tablespace, or adding or dropping rollback segments.

Forcing a Full Resynchronization of the Recovery Catalog

Use RESYNC CATALOG to force a full resynchronization of the recovery catalog.

Connect RMAN to the target and recovery catalog databases, and then mount or open the target database if it is not already mounted or open:
```
STARTUP MOUNT;
```
Run the RESYNC CATALOG command at the RMAN prompt:
```
RESYNC CATALOG;
```
See Also:
Oracle Database Backup and Recovery Reference for RESYNC CATALOG command syntax

Resynchronizing the Recovery Catalog and CONTROL_FILE_RECORD_KEEP_TIME

If you maintain a recovery catalog, then use the RMAN RESYNC CATALOG command often enough to ensure that control file records are propagated to the recovery catalog before they are reused.

Make sure that CONTROL_FILE_RECORD_KEEP_TIME is longer than the interval between backups or resynchronizations. Otherwise, control file records could be reused before they are propagated to the recovery catalog. An extra week is a safe margin in most circumstances.

Caution:

Never set CONTROL_FILE_RECORD_KEEP_TIME to 0. If you do, then backup records may be overwritten in the control file before RMAN is able to add them to the catalog.