Oracle RMAN Resync Catalog Command Guide

calendar Feb 1, 2026 / · 5 min read · Oracle RMAN Database Backup Recovery Catalog DBA Tasks Database Administration Backup and Recovery Oracle Database  ·
Share on: linkedin copy

Oracle RMAN Resync Catalog Command Guide

Purpose

The RESYNC CATALOG command synchronizes the metadata stored in your Oracle RMAN recovery catalog with the current information in the target database control file. This ensures that all backup, restore, and recovery operations use the most accurate and up-to-date database information. The command performs a full comparison between the recovery catalog and control file, updating any missing or changed records.

Original Code

1RESYNC CATALOG;

Breakdown of Code

The RESYNC CATALOG command is a simple, single-line RMAN command that triggers a complete synchronization process. When executed, RMAN creates a snapshot control file to obtain a read-consistent view of the current control file, then updates the recovery catalog with any new information from that snapshot.

Command Structure

  • RESYNC - The action keyword that initiates the synchronization process
  • CATALOG - Specifies that the recovery catalog should be synchronized with the target database control file

Optional Syntax Variations

The command can be extended with additional clauses:

  • RESYNC CATALOG FROM CONTROLFILECOPY 'filename' - Synchronizes using a specific control file copy
  • RESYNC CATALOG FROM DB_UNIQUE_NAME ALL - Synchronizes all databases in a Data Guard environment
  • RESYNC CATALOG FROM DB_UNIQUE_NAME db_name - Synchronizes a specific database by its unique name

Key Points

  • Automatic vs Manual: RMAN automatically performs resynchronization during normal backup operations, but manual resync is needed in specific situations
  • Full Synchronization: The command performs a full resynchronization, updating all changed records for data files, tablespaces, redo threads, and online redo logs
  • Prerequisites: RMAN must be connected as TARGET to a mounted or open database and as CATALOG to a recovery catalog database
  • Performance Impact: The resync operation has minimal impact on production workloads as it mainly reads small amounts of metadata
  • Control File Dependency: The currency of catalog data depends on the currency of control file data, making regular resynchronization important

When to Use RESYNC CATALOG

Recovery Catalog Unavailable

If the recovery catalog database was unavailable when you executed RMAN commands, you should manually resynchronize once the catalog becomes available again. This ensures that all operations performed during the outage are properly recorded in the catalog.

ARCHIVELOG Mode with Infrequent Backups

When your database runs in ARCHIVELOG mode and you back up infrequently, manual resynchronization helps capture redo log metadata. The recovery catalog is not automatically updated when online redo log switches occur or when redo logs are archived.

Physical Structure Changes

After making changes to the physical structure of your database, such as adding or dropping tablespaces or datafiles, run RESYNC CATALOG to update the catalog. The recovery catalog does not automatically update when physical schema changes occur.

Before Control File Records Age Out

The CONTROL_FILE_RECORD_KEEP_TIME parameter determines how long records stay in the control file before being overwritten. You must resynchronize the catalog before these records are erased to preserve backup metadata. Make sure your resynchronization interval is shorter than the CONTROL_FILE_RECORD_KEEP_TIME setting.

Data Guard Environments

When working with standby databases in a Data Guard configuration, use RESYNC CATALOG to update the catalog with metadata about RMAN operations performed on standby databases. This is especially important after physical changes on the primary database are propagated to standby sites.

Insights and Best Practices

Regular Synchronization Schedule

Establish a regular resynchronization schedule based on your database activity level. If your database generates hundreds of log switches daily, more frequent manual resynchronization ensures the catalog stays current.

Data Guard Strategy

In Data Guard environments, use the FROM DB_UNIQUE_NAME ALL clause to synchronize all databases in your configuration with a single command. This keeps the recovery catalog current with changes across your entire environment.

Cost Considerations

The cost of resynchronization is proportional to the number of records that have changed since the last sync. If no records have changed, the operation completes very quickly. If many records have changed, the operation takes more time but still has minimal impact on production.

Network Requirements

When using RESYNC CATALOG with multiple databases, ensure you have network connectivity to each target database. For Data Guard configurations, the password file must be identical on all remote databases for the feature to work properly.

Control File Size Management

Monitor your control file size, as it can grow large with many backups, archived redo logs, and extended retention periods. If the control file reaches maximum capacity, the database may overwrite old records even if they are younger than CONTROL_FILE_RECORD_KEEP_TIME.

Common Use Cases

Example 1: Basic Resynchronization

Connect to your target database and recovery catalog, then execute the command:

1RMAN> CONNECT TARGET /
2RMAN> CONNECT CATALOG rman_user@catalog_db
3RMAN> RESYNC CATALOG;

Example 2: ARCHIVELOG Mode Resync

After archiving all unarchived redo log files, perform a full resynchronization:

1RMAN> ALTER SYSTEM ARCHIVE LOG CURRENT;
2RMAN> RESYNC CATALOG;

Example 3: Data Guard Environment

After adding a datafile to the primary database, synchronize all databases in the Data Guard environment:

1RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;

Troubleshooting

If you encounter issues during resynchronization, verify that:

  • The target database is mounted or open
  • You have proper connectivity to both the target database and recovery catalog
  • The database is already registered with the recovery catalog
  • Network connections are stable for remote database operations
  • Password files are synchronized across Data Guard configurations

References

Posts in this series