RESYNC CATALOG

Purpose

Use the RESYNC CATALOG command to perform a full resynchronization of metadata in a recovery catalog schema with metadata in a target database control file. You can also use the FROM CONTROLFILECOPY clause to resynchronize the current control file with the RMAN metadata in a control file copy.

Typically, you run RESYNC CATALOG in the following situations:

The recovery catalog was unavailable when you executed RMAN commands that automatically perform a resynchronization.
The target database is running in ARCHIVELOG mode, because the recovery catalog is not updated automatically when an online redo log switch occurs or when a redo log is archived.
You made changes to the physical structure of the target database such as adding or dropping a tablespace. As with log archiving, the recovery catalog is not updated automatically when the physical schema changes.
You are connected as TARGET to a standby database and want to update the recovery catalog with metadata about RMAN operations performed on this database.
You are connected as TARGET to a standby database and want to update the recovery catalog with metadata about a physical change on the primary database (see Example 2-123).

Prerequisites

RMAN must be connected as TARGET to a mounted or open database and connected as CATALOG to a recovery catalog database.

Usage Notes

Resynchronizations are full or partial. If full, and if the target database has mounted the current control file (but not a newly created control file or a control file that is less current than a control file that was used previously), then RMAN updates all changed records for the physical schema: datafiles, tablespaces, redo threads, and online redo logs. If the database is open, then RMAN also obtains data about rollback segments. If the resynchronization is partial, then RMAN does not resynchronize metadata about the physical schema or rollback segments.

If the target control file is mounted and the catalog database is available at command execution, then RMAN automatically resynchronizes the recovery catalog as needed when you use RMAN commands. RMAN performs a full resynchronization after structural changes to database (adding or dropping database files, creating new incarnation, and so on) or after changes to the RMAN persistent configuration.

Starting with Oracle Database 11g, a single recovery catalog schema can keep track of database filenames for all databases in a Data Guard environment. This catalog schema also keeps track of where the online redo logs, standby redo logs, tempfiles, archived redo logs, backup sets, and image copies are created for all databases. If RMAN is connected as TARGET to a standby database, then RMAN implicitly executes a full resynchronization if the standby control file contains information about a physical schema change on the primary database.

Syntax

resync::=

Description of the illustration resync.gif

Semantics

Syntax Element Description

Syntax Element	Description
`RESYNC CATALOG`	Updates the recovery catalog with RMAN metadata in the current control file of the target database (default). RMAN creates a snapshot control file in order to obtain a read-consistent view of the control file, then updates the recovery catalog with any new information from the snapshot. The `RESYNC CATALOG` command updates the following classes or records: Log history records, which are created when a log switch occurs. Note that log history records describe an online log switch, not a log archival. Archived redo log records, which are associated with archived logs created by archiving an online redo log, copying an existing archived log, or restoring backups of archived logs. Backup records, which are records of backup sets, backup pieces, proxy copies, and image copies. Physical schema records, which are associated with datafiles and tablespaces. If the target database is open, then rollback segment information is also updated.
`FROM CONTROLFILECOPY` `'filename'`	Updates the current control file and recovery catalog with RMAN metadata from a control file copy (see Example 2-122). Use filename to specify the name of the control file copy to use for resynchronization. The primary use for `FROM CONTROLFILECOPY` occurs when you re-create the control file, which causes you to lose RMAN records stored in the control file. You can then resynchronize the newly created control file with an old copy. Physical schema information is not updated when you use this option. Note: The control file copy can either be in the current database incarnation, or created in a prior incarnation (that is, prior to the most recent `OPEN` `RESETLOGS`).
`FROM DB_UNIQUE_NAME` `{ALL \|` `db_unique_name}`	Resynchronizes the recovery catalog with control file metadata in the specified database or databases (see Example 2-124). You can specify a single database with `db_unique_name` or use `ALL` for all databases in the recovery catalog that share the DBID of the target database. If you specify `ALL`, then RMAN resynchronizes all databases in the Data Guard environment that are known to the recovery catalog. Note: You must have previously used `CONFIGURE DB_UNIQUE_NAME ... CONNECT IDENTIFIER` to specify a net service name to be used for an Oracle Net connection to the database specified in `FROM DB_UNIQUE_NAME`. When you run `RESYNC FROM DB_UNIQUE_NAME` for a specified database, RMAN performs both a normal resynchronization and a reverse resynchronization. In a normal resynchronization, RMAN updates the recovery catalog with metadata from the control file. In a reverse resynchronization, RMAN updates the persistent configurations in the control file if they do not match the information in the recovery catalog for the specified database. For a sample use case, suppose that you recently connected RMAN as `TARGET` to the primary database and ran `CONFIGURE` to create an RMAN configuration for standby database `standby_new`. However, you have not yet connected RMAN as `TARGET` to `standby_new`. In this case, you can run `RESYNC CATALOG FROM DB_UNIQUE_NAME standby_new`. When you later connect RMAN to `standby_new` as `TARGET`, RMAN pushes the configuration from the recovery catalog to the mounted control file of `standby_new`.

RESYNC CATALOG

Updates the recovery catalog with RMAN metadata in the current control file of the target database (default).

RMAN creates a snapshot control file in order to obtain a read-consistent view of the control file, then updates the recovery catalog with any new information from the snapshot. The RESYNC CATALOG command updates the following classes or records:

Log history records, which are created when a log switch occurs. Note that log history records describe an online log switch, not a log archival.
Archived redo log records, which are associated with archived logs created by archiving an online redo log, copying an existing archived log, or restoring backups of archived logs.
Backup records, which are records of backup sets, backup pieces, proxy copies, and image copies.
Physical schema records, which are associated with datafiles and tablespaces. If the target database is open, then rollback segment information is also updated.

FROM CONTROLFILECOPY

'filename'

Updates the current control file and recovery catalog with RMAN metadata from a control file copy (see Example 2-122). Use filename to specify the name of the control file copy to use for resynchronization.

The primary use for FROM CONTROLFILECOPY occurs when you re-create the control file, which causes you to lose RMAN records stored in the control file. You can then resynchronize the newly created control file with an old copy. Physical schema information is not updated when you use this option.

Note: The control file copy can either be in the current database incarnation, or created in a prior incarnation (that is, prior to the most recent OPEN RESETLOGS).

FROM DB_UNIQUE_NAME

{ALL |

db_unique_name}

Resynchronizes the recovery catalog with control file metadata in the specified database or databases (see Example 2-124).

You can specify a single database with db_unique_name or use ALL for all databases in the recovery catalog that share the DBID of the target database. If you specify ALL, then RMAN resynchronizes all databases in the Data Guard environment that are known to the recovery catalog.

Note: You must have previously used CONFIGURE DB_UNIQUE_NAME ... CONNECT IDENTIFIER to specify a net service name to be used for an Oracle Net connection to the database specified in FROM DB_UNIQUE_NAME.

When you run RESYNC FROM DB_UNIQUE_NAME for a specified database, RMAN performs both a normal resynchronization and a reverse resynchronization. In a normal resynchronization, RMAN updates the recovery catalog with metadata from the control file. In a reverse resynchronization, RMAN updates the persistent configurations in the control file if they do not match the information in the recovery catalog for the specified database.

For a sample use case, suppose that you recently connected RMAN as TARGET to the primary database and ran CONFIGURE to create an RMAN configuration for standby database standby_new. However, you have not yet connected RMAN as TARGET to standby_new. In this case, you can run RESYNC CATALOG FROM DB_UNIQUE_NAME standby_new. When you later connect RMAN to standby_new as TARGET, RMAN pushes the configuration from the recovery catalog to the mounted control file of standby_new.

Examples

Example 2-121 Resynchronizing the Recovery Catalog in ARCHIVELOG Mode

This example performs a full resynchronization of the target database after archiving all unarchived redo logs.

CONNECT TARGET /
CONNECT CATALOG rman/password@catdb
SQL "ALTER SYSTEM ARCHIVE LOG CURRENT";
RESYNC CATALOG;

Example 2-122 Resynchronizing the Recovery Catalog from a Control File Copy

This example updates the RMAN repository in the current control file with metadata from a backup control file.

CONNECT TARGET /
CONNECT CATALOG rman/password@catdb
STARTUP FORCE MOUNT
RESYNC CATALOG FROM CONTROLFILECOPY '/disk1/cfile.dbf';
ALTER DATABASE OPEN;

Example 2-123 Resynchronizing the Recovery Catalog After a Structural Change

Suppose that you start SQL*Plus, connect to database prod, and add a datafile to tablespace users as follows:

CONNECT TARGET SYS/password@prod
ALTER TABLESPACE users ADD DATAFILE ''?/oradata/prod/users03.dbf'' 
  SIZE 1M AUTOEXTEND ON 
  NEXT 10K MAXSIZE 10M";

After this change has propagated to standby database standby3, you start RMAN and connect to standby3 and the recovery catalog. You then resynchronize the catalog with the control file of the standby database. The recovery catalog is updated with metadata about the datafile added to prod.

CONNECT TARGET SYS/password@standby3
CONNECT CATALOG rman/password@catdb
RESYNC CATALOG;

Example 2-124 Resynchronizing the Recovery Catalog with a Standby Database

Suppose that primary database prod and standby database dgprod3 exist in a Data Guard environment. You connect RMAN to prod and use CONFIGURE to update the persistent RMAN configuration for dgprod3 in the recovery catalog as follows:

CONNECT TARGET SYS/password@prod
CONNECT CATALOG rman/password@catdb
CONFIGURE DEFAULT DEVICE TYPE TO sbt
  FOR DB_UNIQUE_NAME dgprod3;
CONFIGURE DB_UNIQUE_NAME dgprod CONNECT IDENTIFIER 'inst1';
CONFIGURE DB_UNIQUE_NAME dgprod3 CONNECT IDENTIFIER 'inst3';

You have not yet performed any backups or other RMAN operations on dgprod3, so the control file of dgprod3 and the recovery catalog configuration for dgprod3 are not synchronized. In the same RMAN session, you synchronize the control file of dgprod3 with the recovery catalog as follows:

RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3;

RMAN updates the default device type to SBT at dgprod3 and also updates the recovery catalog with the names from the dgprod3 control file.