When to Resynchronize an RMAN Recovery Catalog

Lesson 5 demonstrated how to connect Recovery Manager (RMAN) to a target database and recovery catalog, issue RESYNC CATALOG, and verify the result. This lesson concentrates on the operational decision: when should a database administrator allow RMAN to resynchronize automatically, and when should the administrator deliberately force a full resynchronization?

A recovery catalog stores RMAN metadata outside the target database. During resynchronization, RMAN reads new or changed repository records from the target database control file and updates the catalog. For a full resynchronization, RMAN obtains a consistent view through a snapshot control file. The process does not compare one control file with another, scan backup storage, or prove that recorded backup pieces are readable.

The central principle is simple: manual resynchronization is an operational control, not a ritual after every database event. Most catalog-aware RMAN work keeps the catalog current automatically. A manual command is useful when automatic synchronization could not occur, when important metadata must be visible before the next normal RMAN job, or when a specialized CDB or Data Guard workflow requires an explicit source.

Automatic resynchronization is the normal behavior

When RMAN is connected to the target and recovery catalog, the current target control file is mounted, and the catalog is available, most RMAN commands perform an automatic resynchronization. Depending on the command and the changes RMAN detects, the operation can be partial or full.

RMAN normally performs a full resynchronization after detecting structural changes, such as adding or dropping database files, after a new database incarnation is created, and after persistent RMAN configuration changes. A SQL statement that adds a data file, a redo log switch, or the archiving of an online redo log updates the target control file. The database event does not independently connect to the recovery catalog. The next qualifying catalog-aware RMAN operation can transfer those records.

Situation 1: the recovery catalog was unavailable

An RMAN operation can use the target control file as its repository when the recovery catalog is not connected or is temporarily unavailable. The control file receives the backup, image-copy, archived-log, and maintenance metadata created by the operation. The unavailable catalog cannot receive those records at that time.

After service is restored, connect RMAN to the same target DBID and the intended catalog owner. The following example uses the target service prodcdb, the common target operator backup_admin, the catalog service catpdb, and catalog owner rco:

rman

CONNECT TARGET "backup_admin@prodcdb AS SYSBACKUP";
CONNECT CATALOG rco@catpdb;
RESYNC CATALOG;

Allow RMAN to prompt for passwords. Do not put passwords in command-line arguments, scripts, job logs, screenshots, or course examples. A successful command should be followed by a focused LIST, REPORT, or SHOW check for metadata created during the outage.

Resynchronization can transfer only records that still exist in its control-file source. If reusable records have already been overwritten, ordinary resynchronization cannot recreate them. Depending on the surviving evidence, recovery may require an approved older control-file copy or a supported CATALOG operation.

Situation 2: operations alternate between catalog and NOCATALOG mode

Some organizations deliberately run remote or availability-sensitive jobs in NOCATALOG mode. Others use it temporarily during a catalog outage. In both cases, the target control file remains the repository for that RMAN activity. Schedule a later catalog-aware operation or manual RESYNC CATALOG before the required control-file records become eligible for reuse.

Do not assume that opening a connection to the catalog alone transfers every record. A qualifying RMAN command must complete. Operational records should identify which jobs ran without the catalog, the target DBID, their start and completion times, and the time of the next verified synchronization. Frequent changes between catalog and NOCATALOG operation make this evidence especially important.

Situation 3: archived-log volume is high

ARCHIVELOG mode does not require a manual resynchronization after every log switch. The scheduling risk appears when large numbers of redo logs are switched and archived, catalog-aware RMAN work is infrequent, and archived-log history in the control file could be reused before the next automatic resynchronization.

Log switches and archived redo log creation update the target control file, not the recovery catalog directly. When hundreds or thousands of archived logs can accumulate between catalog-aware jobs, Oracle recommends periodic manual resynchronization. The work required is related to the number of inserted or changed records since the previous synchronization. Frequent small updates are normally less expensive than one delayed update containing a very large archived-log delta.

Choose the interval from measured redo generation, control-file capacity, catalog availability, and recovery-reporting requirements. Afterward, use a time-bounded inventory rather than listing an unlimited production history:

LIST ARCHIVELOG FROM TIME 'SYSDATE-1';

This command checks repository inventory for the selected period. It does not prove that every listed file is physically present or readable. Use CROSSCHECK or validation operations when storage status or backup integrity is the actual question.

Situation 4: control-file records are approaching reuse age

The recovery catalog can receive only records still present in the selected control file. Plan at least one successful catalog-aware backup or manual resynchronization within an interval shorter than CONTROL_FILE_RECORD_KEEP_TIME. This initialization parameter specifies the minimum age at which reusable control-file records can generally become candidates for reuse.

Do not set CONTROL_FILE_RECORD_KEEP_TIME to 0 as a general RMAN design. A zero setting allows reusable records to be overwritten without regard to age. Oracle describes adding approximately one week beyond the planned synchronization interval as a generally safe margin, but the final value must reflect the measured workload and recovery requirements.

The setting is not a promise of unlimited retention. If the control file reaches its maximum capacity, records can be reused sooner, and Oracle reports the condition in the alert log. Monitor the following factors together:

• the frequency and volume of RMAN backups and image copies;
• the rate of archived redo log generation;
• the number of days of repository metadata that remain available;
• control-file section growth and capacity warnings;
• resynchronization frequency, duration, and failures; and
• failures of catalog-aware backup and maintenance jobs.

If control-file growth repeatedly approaches a platform limit, Oracle documents reducing the keep time while increasing synchronization frequency. Increasing the parameter indefinitely without measuring control-file growth is not a capacity-management strategy.

Situation 5: important structural or configuration changes need immediate visibility

Automatic full resynchronization normally follows detected physical-schema, incarnation, or persistent-configuration changes during qualifying catalog-aware RMAN work. A manual full resynchronization becomes useful when the catalog must show the change before that work occurs or when the catalog was unavailable during the automatic opportunity.

Relevant examples include adding or dropping a tablespace or data file, changing a data-file status, creating a new incarnation with OPEN RESETLOGS, changing redo-thread or online redo-log metadata, and modifying persistent RMAN configuration. Verify the specific metadata category after resynchronization:

REPORT SCHEMA;
LIST INCARNATION OF DATABASE PRODCDB;
SHOW ALL;

These checks have different purposes. REPORT SCHEMA examines the recorded physical schema, LIST INCARNATION displays incarnation history, and SHOW ALL displays persistent RMAN configuration. Oracle AI Database uses automatic undo management in normal deployments, so legacy manual rollback-segment administration is not a current resynchronization scenario.

Situation 6: RMAN requires a full resynchronization from CDB root

A PDB-scoped target connection does not always provide the CDB-wide metadata required after a database role change or the discovery of a new database site. RMAN can report the following error:

RMAN-20025: full resync from CDB$ROOT database is not done

Connect RMAN to the target CDB root and recovery catalog, complete a full RESYNC CATALOG, and retry the original command. Do not reconnect to an ordinary PDB or suppress the error. Confirm that the target service reaches CDB$ROOT, then verify the database name, DBID, DB_UNIQUE_NAME, role, and container before resynchronizing.

Situation 7: Data Guard metadata or configuration changed

A recovery catalog coordinates repository metadata for the primary and physical standby databases in a Data Guard environment. A target connection to one member does not automatically read every control file associated with the shared DBID. After a standby is configured or its connectivity changes, RMAN can require ordinary resynchronization from a database control file and reverse resynchronization of applicable persistent configuration from the catalog to a member's control file.

To synchronize a particular configured member, identify it by DB_UNIQUE_NAME:

RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;

The member must have a configured connect identifier, such as one established by CONFIGURE DB_UNIQUE_NAME ... CONNECT IDENTIFIER. Oracle Net connectivity, password-file configuration, and authentication must satisfy the requirements documented for that workflow.

An advanced operation can request synchronization for all known databases that share the target DBID:

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;

The ALL form is not the default single-database command. It has a stricter authentication requirement: RMAN must connect to the target as SYS by using password-file authentication. Do not replace this requirement with the ordinary SYSBACKUP connection shown earlier, and do not place the SYS password on the command line.

Oracle 26ai physical-standby behavior

In Oracle AI Database 26ai, RMAN connected to a physical standby as TARGET can perform a full resynchronization from the standby control file. Earlier releases limited this target context to a partial resynchronization. The 26ai capability can avoid a primary connection, but it does not guarantee that every standby can always supply a complete full resynchronization.

RMAN can require or fall back to the primary when the standby control file is converted, when PDB dictionary checks prevent the standby path, or when required connection information is unavailable. Oracle 26ai also permits explicit physical-standby registration. A successful REGISTER DATABASE from the physical standby includes a full resynchronization, so an immediate duplicate RESYNC CATALOG is not normally necessary.

Oracle 26ai uses resynchronization savepoints to improve transactional recovery when a full resynchronization is interrupted. A savepoint improves restart behavior, but it does not make a failed resynchronization complete. Review the RMAN output, correct the failure, and allow the required work to finish.

Situation 8: recover repository metadata from a control-file copy

If the current control file was re-created and older RMAN repository records were lost, a verified control-file copy may contain records absent from the current file:

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

This clause is a specialized metadata-recovery workflow, not a routine scheduling technique. The copy must belong to the intended target DBID and can come from the current or a previous incarnation. Before using it, preserve current evidence and verify the copy's DBID, incarnation, checkpoint, path, and accessibility.

FROM CONTROLFILECOPY can update RMAN metadata in the current control file and recovery catalog, but it does not refresh the current physical-schema metadata. It is also not a directory scanner. If an eligible backup or archived log exists on storage but neither repository knows about it, use an appropriate CATALOG workflow after confirming ownership, identity, and scope.

Choose the command that matches the repository problem

Catalog currency, physical file availability, retention status, and backup integrity are separate concerns. Using the correct RMAN command avoids treating RESYNC CATALOG as a universal repair operation.

Manage recovery-catalog growth with supported operations

Recovery-catalog growth depends on the number of registered databases, archived-log volume, backup activity, retained history, stored scripts, and Data Guard metadata. Monitor the catalog database's tablespace use and query performance as part of normal capacity management.

The Fast Recovery Area and retention policy help determine which recovery files are eligible for deletion. They do not guarantee that repository metadata is current or that every recorded file remains available. If a recorded file was moved or removed outside RMAN, use CROSSCHECK to reconcile its availability. Use DELETE OBSOLETE when a backup is no longer required under the approved retention policy.

Never issue SQL DELETE statements against internal recovery-catalog tables such as DBINC. Those tables are implementation details, and direct modification can damage recovery history or leave the catalog schema unsupported. Old incarnation records are normally retained as useful historical metadata. If catalog growth, performance, or corruption appears abnormal after supported maintenance, collect diagnostics and work with Oracle Support.

Build and verify an operational schedule

There is no universal rule that every database should issue RESYNC CATALOG once per day. Derive the interval from the shortest relevant control-file record-retention window, maximum expected catalog outage, archived-log generation rate, frequency of catalog-aware RMAN jobs, Data Guard topology, role-change procedures, required report currency, and measured resynchronization duration.

The schedule must produce at least one successful catalog-aware backup or manual resynchronization before required control-file records can become overwrite candidates. Alert on missed executions and on apparent success against the wrong target or catalog. Preserve the following evidence for each scheduled run:

• target database name, DBID, DB_UNIQUE_NAME, role, and container;
• catalog service and catalog schema owner;
• start and completion time;
• the full-resynchronization completion message;
• all relevant warnings and the complete RMAN error stack; and
• focused post-resynchronization inventory results.

A process exit without an operating-system error is not sufficient proof if the script never connected to the intended database or never issued the command. Confirm the target identity before the operation and verify the affected repository category afterward.

Register, Resynchronize, and Reset RMAN Quiz

Test your understanding of RMAN registration, recovery-catalog resynchronization, and reset operations:

Register, Resynchronize, and Reset RMAN Quiz

In the next lesson we will discuss, how resynchronization transfers available metadata from a known control-file source into the recovery catalog. It does not independently change the status or attributes assigned to repository records. Lesson 7 explains how the RMAN CHANGE command performs those supported repository changes.