Oracle RMAN Recovery Catalog Maintenance Basics

Module 3 established how Recovery Manager uses the target control file as an RMAN repository, why an organization may add a recovery catalog, and how to create the catalog schema and register a target database. Registration begins the catalog lifecycle. From that point forward, administrators must keep the catalog's metadata accurate, preserve its longer history, protect the catalog database, and control operations that can remove unique records.

This module introduces those responsibilities for Oracle AI Database 26ai. It covers starting RMAN with and without a catalog, registering and unregistering databases, selecting a database incarnation, resynchronizing metadata, reconciling repository records with backup media, validating files and backups, and upgrading the catalog schema. These operations do not all perform the same kind of maintenance, and several are destructive if used without verifying the connected database and the intended scope.

The examples continue the Module 3 environment. The target CDB uses the service prodcdb, the target operator is backup_admin, and the catalog owner rco connects to the catalog PDB through catpdb. These are placeholders. Use approved services, accounts, authentication controls, and change procedures in an actual environment.

The term recovery catalog maintenance is sometimes used too broadly. The catalog is a database schema that stores synchronized RMAN metadata for registered targets. Backup files reside on disk, tape, appliances, or supported cloud destinations. The target control file also retains RMAN repository records. A command can affect one of these areas without performing an integrity check on all the others.

Three RMAN maintenance responsibilities

Responsibility	Purpose	Representative operations
Metadata synchronization	Keep catalog metadata aligned with the mounted target control file	Automatic resynchronization and RESYNC CATALOG
Catalog lifecycle administration	Manage registration, incarnation history, schema version, access, and availability	RESET DATABASE, UNREGISTER, UPGRADE CATALOG, and catalog backup
Backup and repository maintenance	Reconcile recorded objects with media and apply retention decisions	CATALOG, CROSSCHECK, CHANGE, and DELETE

These responsibilities interact. For example, a crosscheck changes repository status, and RMAN can propagate that change to a connected catalog. That does not make CROSSCHECK a catalog-schema integrity test. Similarly, VALIDATE can use catalog metadata to locate an object, but it checks database files, blocks, or backup restoreability rather than the catalog tables themselves.

Every maintenance session should begin with a deliberate connection plan. The target connection identifies the database whose files and repository metadata RMAN will manage. The catalog connection identifies a separate database service and the schema that owns the base recovery catalog. The target database instance never accesses the recovery catalog directly. RMAN reads target metadata and maintains the catalog through its own database connections.

The following example connects to both databases and allows each service-based account to authenticate interactively. Do not place reusable passwords on the operating-system command line, in shell history, or in a published script.

rman TARGET backup_admin@prodcdb CATALOG rco@catpdb

For a local target connection, an installation with correctly configured operating-system authentication can instead use TARGET /. A remote target operator should use an approved account with the least administrative privilege required for the task, commonly SYSBACKUP, instead of relying on routine SYSDBA use.

To work without a recovery catalog, make the choice explicit:

rman TARGET / NOCATALOG

NOCATALOG does not mean that RMAN has no repository. It means the target control file is the exclusive repository for that session. RMAN also permits a session to start without either CATALOG or NOCATALOG. If no catalog connection is made, the first command that requires repository access commits the session to NOCATALOG mode. The operator must then exit and restart RMAN before connecting to a recovery catalog.

Explicit modes make interactive work, scheduled jobs, and incident transcripts easier to review. They also reduce the chance that a command intended for a catalog-aware session runs only against the control-file repository, or that a catalog operation is performed against the wrong catalog PDB.

For RMAN operations such as backup, restore, and crosscheck, RMAN updates repository metadata in the mounted target control file first. When the target is registered and the catalog is connected, RMAN propagates changed metadata from that control file to the recovery catalog. This flow is called recovery catalog resynchronization.

Resynchronization normally occurs automatically when RMAN has the required connections. A manual resynchronization is therefore not a command that must follow every backup. It is used when a documented condition requires RMAN to bring catalog metadata current, such as after relevant work in NOCATALOG mode, selected control-file changes, or a recovery and Data Guard workflow that requires a full resynchronization.

RMAN> RESYNC CATALOG;

The command is RESYNC CATALOG, and the process is called resynchronization. The legacy misspelling in the source is not an RMAN command. Later lessons examine full and partial resynchronization, control-file record retention, control-file copies, and the conditions under which manual action is appropriate.

Catalog history can extend beyond the reusable records in the target control file. That longer history is one of the catalog's principal benefits, but it also creates a protection responsibility. If catalog-only history is lost, registering the target again can restore only the records still available in its control file and any backup files that can be recataloged.

Oracle AI Database 26ai introduces several catalog-related improvements. First, RMAN automatically disconnects from the recovery catalog before it performs a target database backup operation. Releasing a catalog connection that is not needed during the backup reduces load on the catalog database server. It does not change the control-file-first repository model or eliminate the need to monitor catalog synchronization.

Second, resynchronization transactions now use multiple predefined savepoints. If an unexpected failure occurs during a long resynchronization, RMAN can roll back to a recent savepoint instead of discarding the entire transaction. This improves transactional resilience, but it does not replace catalog backups, capacity monitoring, connection monitoring, or investigation of repeated resynchronization failures.

Third, when RMAN is connected to a physical standby database as TARGET, 26ai can perform a full resynchronization from the standby control file. This can avoid connecting to the primary only to perform that full resynchronization. The standby path has documented limitations and can fall back to the primary control file when the standby control file cannot be used. A Data Guard runbook must account for the DBID shared by the physical databases and their distinct DB_UNIQUE_NAME values.

Oracle 26ai also introduces a catalog maintenance mode for controlling catalog-schema connections during UPGRADE CATALOG. Despite its general-sounding name, this mode is not required for normal backup, crosscheck, deletion, reporting, or resynchronization work.

A database incarnation represents a branch of database history created by opening with RESETLOGS. Oracle normally creates the new incarnation record and makes it current automatically. The command RESET DATABASE TO INCARNATION is needed when a recovery must return to an earlier branch and RMAN cannot select that branch implicitly.

RMAN> LIST INCARNATION OF DATABASE;
RMAN> RESET DATABASE TO INCARNATION 2;

The incarnation key 2 is only an example. The DBA must list the available incarnations, identify the intended recovery timeline, and verify the required backups and redo before changing the current incarnation. Selecting the wrong key can direct subsequent restore and recovery work to the wrong branch of history.

This operation does not reset or empty the recovery catalog. It changes the incarnation that RMAN treats as current for subsequent work. The complete procedure can also require restoring an older control file, mounting it, restoring and recovering the database, and opening with RESETLOGS. Those steps belong in a tested recovery runbook rather than an improvised maintenance session.

Four commands are frequently grouped together even though they answer different operational questions. Selecting a command by name rather than by its effect can leave valid files untracked, mark temporarily inaccessible media as missing, or remove the only backup that satisfies a recovery window.

RMAN backup and repository maintenance commands

Command	Question answered	Typical effect
CATALOG	Which existing files should RMAN begin tracking?	Adds repository metadata for recognized backup pieces, copies, or archived logs
CROSSCHECK	Are tracked objects accessible through their recorded device type?	Changes repository status between AVAILABLE and EXPIRED
CHANGE	How should selected metadata or status be altered?	Changes status, retention exemption, association, or uncatalogs a record
DELETE	Which selected backups or copies should be removed?	Deletes physical objects and their repository records when possible

EXPIRED and OBSOLETE describe different conditions. An object is expired when a crosscheck cannot find or access it through the allocated device type. An object is obsolete when the configured retention policy determines that it is no longer needed. An available backup can be obsolete, and a backup required by the retention policy can appear expired because storage or media-management access failed.

The preferred baseline is an approved backup retention policy, archived redo log deletion policy, monitored destinations, and a fast recovery area where appropriate. Before broad deletion, list the affected objects, confirm that required recovery points remain protected, investigate unexpected expiration, and preserve any archival backups protected by a valid KEEP requirement.

The RMAN VALIDATE command does not check the validity of the recovery catalog schema. It reads selected database files to find missing files or corrupt blocks. A restore validation determines whether RMAN can locate and read the backup material needed by a restore without writing restored data files.

RMAN> VALIDATE DATABASE;
RMAN> RESTORE DATABASE VALIDATE;

These operations provide useful evidence, but neither proves that an application can be recovered within its required recovery point objective and recovery time objective. A complete rehearsal also exercises storage access, service resolution, credentials, encryption keys, the SPFILE and control file, archived redo, capacity, documentation, and the operator's ability to make the correct recovery decisions.

Maintain confidence in the catalog through supported catalog connections and reports, schema-version checks, database health monitoring, physical catalog-database backups, optional Data Pump logical exports, and catalog recovery tests. Do not update catalog-owner tables directly or invent a nonexistent general VALIDATE CATALOG command.

Unregistering removes a database's RMAN repository records from the recovery catalog. It also removes local stored scripts associated with that database because those scripts exist only in the catalog. Verify the connected catalog, target name, DBID, DB_UNIQUE_NAME, stored scripts, Data Guard relationships, and required history before proceeding.

RMAN> UNREGISTER DATABASE;

The basic form uses the connected target's identity and prompts for confirmation. A catalog-only workflow can identify a uniquely named database or use the documented DBID procedure when names are ambiguous. Do not add NOPROMPT to an introductory example, and do not unregister a target merely to clear a registration error.

UNREGISTER DATABASE does not delete the target database, physical backup files, or repository records from the target control file. If the database is registered again, RMAN rebuilds catalog content from records that still exist in that control file. Older catalog-only records and local stored scripts are not restored by re-registration. Physical files require separate, deliberately scoped DELETE operations.

In a Data Guard environment, unregistering a primary can also affect its associated standby databases. The more targeted UNREGISTER DB_UNIQUE_NAME form has different metadata behavior. Data Guard removal must therefore follow its own reviewed procedure rather than the ordinary single-target example.

The recovery catalog database is a production database dependency and must have an independent recovery plan. Oracle recommends frequent physical backups, ARCHIVELOG operation when point-in-time recovery is required, control-file autobackups, more than one retained backup, and copies on separate media or failure domains. Avoid circular dependency by backing up the catalog database with its own control file as the repository.

rman TARGET / NOCATALOG

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Adapt the command, channels, encryption, destination, retention, and archived-log handling to the approved catalog-database plan. Data Pump Export can provide a useful logical supplement and Data Pump Import can help reconstruct catalog data in another database, but a logical export does not replace physical backups, archived redo, control-file autobackups, or a tested recovery procedure. The legacy exp and imp utilities should not be presented as the primary protection method.

When the catalog schema is older than the version required by the RMAN client, complete Oracle's compatibility, privilege, edition, Partitioning, backup, and change-control prerequisites before issuing UPGRADE CATALOG. Oracle 26ai can enable maintenance mode during an upgrade so the catalog owner can inspect blocking or waiting schema connections.

RMAN> SET CATALOG MAINTENANCE ON;
RMAN> LIST BLOCKING CONNECTED USERS;
RMAN> TERMINATE BLOCKING CONNECTED USERS;
RMAN> SET CATALOG MAINTENANCE OFF;

This sequence is conceptual, not a routine command block. It applies only in the catalog-upgrade context. TERMINATE is forceful and can end active work, so the operator must identify session ownership, confirm that UPGRADE CATALOG is in progress, assess the business impact, and obtain the required authorization before terminating connections. Maintenance mode is not required for normal resynchronization, reporting, crosscheck, or deletion.

By the end of this module, you should be able to:

1. Start RMAN with explicit target and recovery-catalog connections without exposing credentials.
2. Start RMAN in NOCATALOG mode and explain the target control file's repository role.
3. Register a target database and verify its database name, DBID, and catalog metadata.
4. List database incarnations and explain when RESET DATABASE TO INCARNATION is required.
5. Explain automatic resynchronization and use RESYNC CATALOG for a documented manual-resynchronization condition.
6. Distinguish CATALOG, CROSSCHECK, CHANGE, and DELETE by their effects.
7. Distinguish available, expired, and obsolete backups before applying a retention or deletion decision.
8. Use validation for documented file and restoreability checks without treating it as catalog-schema or recovery proof.
9. Unregister a database only after protecting required history, scripts, backups, and Data Guard relationships.
10. Protect the catalog database and identify when its schema requires a controlled upgrade.

Some operations in this module occur rarely, but rarity increases the value of precise runbooks, protected credentials, command transcripts, and rehearsals. Do not depend on memory during an incident or assume that an old certification example still represents current Oracle behavior.

In Lesson 2, you will start RMAN with explicit target and recovery-catalog connections and verify both identities before issuing repository-dependent commands.