Resynchronize an RMAN Recovery Catalog

Lesson 4 explained how OPEN RESETLOGS creates a new database incarnation. That incarnation and other control-file changes must reach the recovery catalog before the catalog can provide complete historical reporting. Resynchronization is the RMAN operation that transfers new or changed repository metadata from a target database control file into the catalog.

The current command is RESYNC CATALOG. It resynchronizes the recovery catalog from the target control file. It does not copy data files, backup pieces, archived redo log contents, or database blocks into the catalog database. The catalog receives metadata that describes those objects.

RMAN normally writes operational metadata to the target control file first. A full resynchronization then follows this path:

Target control file -> snapshot control file -> recovery catalog

The snapshot control file gives RMAN a read-consistent source. The recovery catalog remains a secondary repository whose currency depends on records still available in the target control file.

The examples continue the target and catalog identities used in the preceding lessons. Replace them with approved values and confirm each identity before transferring metadata.

Example RMAN resynchronization environment

Component	Example	Expected scope
Target service	prodcdb	Target CDB root
Target operator	backup_admin	Common user granted SYSBACKUP
Catalog service	catpdb	PDB containing the recovery catalog
Catalog owner	rco	Dedicated owner of the catalog schema

A connection to the wrong target can associate current metadata with an unintended operational session. A connection to the wrong catalog PDB can update the wrong schema or fail because the target is not registered. Compare the target database name, DBID, DB_UNIQUE_NAME, role, and container with the approved record before running RESYNC CATALOG.

Recovery-catalog resynchronizations are full or partial. Both read metadata from a target control file, but they refresh different classes of records.

Full and partial recovery-catalog resynchronization

Type	Typical initiation	Metadata scope	Physical schema
Partial	Performed automatically as needed	New backups, archived logs, data-file copies, and similar changes	Not refreshed
Full	Explicit command or detected full-resync condition	All changed records, including schema and persistent configuration	Refreshed from a consistent snapshot

A full resynchronization updates changed records for data files, tablespaces, redo threads, and online redo logs. When the target is open, RMAN can also obtain the rollback-segment information documented for this process. Oracle 26ai normally uses automatic undo management, so this is not a reason to revive legacy manual rollback-segment administration.

An explicit RESYNC CATALOG forces a full resynchronization. RMAN still transfers only records that are new or changed, but the operation evaluates the complete metadata scope rather than performing only a partial refresh.

Most RMAN commands resynchronize automatically when RMAN is connected to the target and recovery catalog, the current target control file is mounted, and the catalog is available. Oracle does not limit this behavior to a fixed list of three commands.

A database event does not independently open an RMAN catalog connection. A log switch, archived-log creation, or SQL structural change updates the target control file. The next qualifying catalog-aware RMAN operation can propagate the change automatically. Manual resynchronization is useful when the catalog must be current before that operation or when an earlier opportunity was missed.

Common reasons for a manual full resynchronization

Situation	Reason
Catalog was unavailable during RMAN work	The target control file received metadata that the catalog could not receive
High log-switch volume with infrequent catalog-aware work	Log-history and archived-log records can accumulate or age out
Recent physical-schema or incarnation change	A deliberate full refresh establishes current structure and branch metadata
Persistent RMAN configuration changed	The catalog needs the changed configuration records
Control-file records approach reuse age	Records must reach the catalog before the control file reuses them
Data Guard metadata or configuration changed	A primary or standby can require normal or reverse resynchronization

REGISTER DATABASE already copies pertinent control-file metadata and performs registration resynchronization. Registration does not automatically require another immediate manual resync unless later or missed changes justify it.

Start the RMAN client without embedding credentials:

rman

Connect to the target CDB root with the task-specific administrative identity:

CONNECT TARGET "backup_admin@prodcdb AS SYSBACKUP";

RMAN requests the target password. Connect separately to the catalog as its schema owner:

CONNECT CATALOG rco@catpdb;

The catalog owner does not connect with SYSBACKUP or SYSDBA. Passwords must not appear in command-line arguments, command files, logs, screenshots, or published examples. Read the connection messages and confirm the target name, DBID, catalog service, and schema before continuing.

The target must be mounted or open, and the recovery catalog database and catalog PDB must be available. If the target instance is started but not mounted, use the approved instance-state procedure. Do not shut down or remount a healthy open database merely because an example shows STARTUP MOUNT.

A full resynchronization uses the configured snapshot control file. Inspect its name before execution:

SHOW SNAPSHOT CONTROLFILE NAME;

The target host must be able to create and access that file. In Oracle RAC, the location must be shared storage accessible to every instance. Verify the path, directory ownership, permissions, free space, and job schedule. Only one RMAN session can use a snapshot control file at a time, so coordinate concurrent backups, restores, and catalog work that require it.

After verifying both connections and the snapshot control-file location, run:

RESYNC CATALOG;

RMAN creates the snapshot control file, obtains a consistent view of the current target control file, and updates new or changed records in the recovery catalog. Read the complete output. A successful operation reports that the full resynchronization started and completed. Do not validate success by matching historical message numbers copied from another release.

The basic operation does not require a backup channel or a media-management channel. Target and catalog database connections perform the metadata work. The default source is the current target control file, so do not add FROM CONTROLFILECOPY to the routine procedure.

Treat the RMAN transcript as an operational record, not as decorative console output. A normal full resynchronization identifies the target and catalog connections, reports that a full catalog resynchronization is starting, and reports successful completion. Preserve the transcript with the job identifier, execution time, target DBID, DB_UNIQUE_NAME, and catalog service. This evidence helps distinguish a completed metadata transfer from a script that started RMAN but never ran the command.

A completion message confirms that the catalog transaction completed. It does not confirm that every expected backup was present in the source control file. Compare the post-resync inventory with the operational event that prompted the command. For example, after an incarnation change, inspect incarnation history; after a configuration change, inspect persistent configuration; after a catalog outage, inspect backups and archived logs created during the outage.

Warnings and errors must be interpreted from the first meaningful failure in the stack. A later message may describe the consequence, such as a failed resynchronization, while an earlier message identifies the cause. Record the complete stack before reconnecting or rerunning the command.

Troubleshoot by boundary: identity, connectivity, target state, snapshot control file, catalog schema, and source metadata. Avoid repeatedly running the command without correcting the first verified failure.

Common resynchronization failure boundaries

Observed condition	Check first	Safe response
Target or catalog connection fails	Service resolution, listener reachability, credentials, privilege, and intended PDB	Correct the connection independently, then reconnect RMAN
Target is not mounted	Instance state and approved maintenance window	Use the authorized state-transition procedure; do not disrupt an open database
Snapshot control file cannot be created	Configured path, ownership, permissions, free space, and concurrent RMAN use	Correct storage access or scheduling, then retry
Catalog rejects the operation	Catalog schema version, registration, schema health, and catalog database availability	Resolve the catalog condition with the catalog administrator
Expected historical records remain absent	Whether the source control file still contains them and whether files exist only on storage	Use an appropriate older control-file copy or CATALOG workflow after verification
Data Guard member cannot be synchronized	Database role, DB_UNIQUE_NAME, connect identifiers, and standby limitations	Correct configuration or use the documented primary-database fallback

Do not delete catalog records, restore a control file, recreate the catalog, or change a database incarnation merely to clear a resynchronization error. Those actions change recovery evidence or database state and require a separate, verified reason. Resynchronization is a metadata-copy operation; its troubleshooting should preserve both the target control file and the catalog until the cause is understood.

Oracle AI Database 26ai adds multiple predefined savepoints to the recovery-catalog resynchronization transaction. As RMAN propagates metadata, these savepoints capture consistent progress. If an unexpected failure occurs late in a long resynchronization, RMAN can roll the transaction back to the most recent applicable savepoint instead of discarding the entire transaction's progress.

A savepoint does not make a failed resynchronization successful. Preserve the error stack, identify whether the target, catalog, network, storage, snapshot control file, or catalog schema caused the failure, and correct that condition. Reconnect, rerun the approved operation, and verify a final completion message. Do not assume that metadata is fully current merely because savepoint recovery was possible.

RMAN's full-resynchronization completion message is the primary evidence. Follow it with read-only checks related to the change that motivated the operation:

REPORT SCHEMA;
LIST INCARNATION OF DATABASE PRODCDB;
LIST BACKUP SUMMARY;
LIST ARCHIVELOG ALL;
SHOW ALL;

REPORT SCHEMA checks physical-schema metadata. LIST INCARNATION checks branch history after OPEN RESETLOGS or an incarnation operation. Backup and archived-log lists check repository inventory, while SHOW ALL checks persistent RMAN configuration. Run only the checks relevant to the change because large archived-log inventories can produce excessive output.

These commands do not prove that backup files exist, media is readable, or recovery objectives can be met. CROSSCHECK, VALIDATE, restore validation, and recovery rehearsal provide different evidence. Resynchronization improves metadata currency, not backup integrity.

The catalog can receive only records still present in the source control file. Keep the interval between catalog-aware backups or manual resynchronizations shorter than CONTROL_FILE_RECORD_KEEP_TIME. Do not set this parameter to 0, which permits reusable records to be overwritten without regard to age.

The parameter specifies a minimum age before reusable records become overwrite candidates, not unlimited retention. A control file that reaches its maximum capacity can reuse records sooner and write a warning to the alert log. Monitor control-file growth, backup volume, archived-log volume, alert-log messages, and resynchronization duration.

Choose the setting from measured workload and required recovery history. Oracle describes an extra week beyond the synchronization interval as a generally safe margin, but that is guidance rather than one correct value for every database.

The specialized syntax is:

RESYNC CATALOG FROM CONTROLFILECOPY '/approved/path/controlfile_copy.ctl';

This clause updates the current control file and recovery catalog with RMAN metadata from the specified control-file copy. Its primary use is after a control file was re-created and repository records were lost from the new file. The copy can come from the current or a prior database incarnation, but it must belong to the intended target DBID.

The clause does not restore that copy as the mounted control file, refresh physical-schema information, or discover arbitrary backup files absent from both control files. Preserve current evidence and verify the source DBID, incarnation, checkpoint, path, and accessibility before importing older repository records.

Related RMAN repository commands

Command	Primary purpose	Boundary
RESYNC CATALOG	Transfers changed metadata from a known control-file source	Does not scan storage for unknown files
CATALOG	Adds eligible files not recorded in the repository	Does not prove complete recoverability
CROSSCHECK	Compares recorded files with accessible storage	Does not recover missing control-file history
LIST or REPORT	Displays repository inventory or analysis	Does not update metadata or validate bytes
VALIDATE	Reads database files or backup data in the selected form	Does not replace catalog resynchronization

If a backup is absent from the catalog but recorded in the target control file, resynchronization can transfer its record. If a backup file exists on storage but neither repository knows it, use the appropriate CATALOG operation. RESYNC CATALOG does not scan a directory, Fast Recovery Area, tape library, or cloud destination for unknown files.

RMAN normally resynchronizes from the control file of the database connected as TARGET. A connection to one database does not automatically read every primary and standby control file that shares its DBID.

Starting with Oracle AI Database 26ai, RMAN connected to a physical standby as TARGET can perform a full resynchronization using the standby control file. This can avoid connecting to the primary. RMAN can fall back to the primary or report an error when V$DATABASE.CONTROLFILE_CONVERTED is YES, a PDB dictionary check prevents the standby path, or required connect identifiers are unavailable.

A specific Data Guard member can be synchronized with:

RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;

This form performs normal resynchronization from the specified control file and reverse resynchronization of applicable persistent configuration metadata. The ALL form has stricter requirements, including a target connection as SYS through password-file authentication and configured connection information. Lesson 6 expands the situations and scheduling decisions for manual resynchronization.

1. Confirm the target database name, DBID, DB_UNIQUE_NAME, role, and root-container scope.
2. Confirm that the catalog service reaches the PDB containing the intended catalog owner.
3. Keep all passwords out of command lines, files, logs, and screenshots.
4. Verify that the target is mounted or open and the catalog database is available.
5. Check the snapshot control-file path, permissions, capacity, and Oracle RAC visibility.
6. Coordinate other RMAN work that could need the same snapshot control file.
7. Run RESYNC CATALOG and read the complete result.
8. Verify the metadata category that motivated the resynchronization.
9. Preserve errors and correct their cause before rerunning a failed operation.
10. Keep the resynchronization interval inside the control-file record-retention window.