Catalog Existing RMAN Backups in Oracle 26ai

Oracle Recovery Manager (RMAN) normally records a backup when it creates the backup. There are also situations in which a valid backup file or image copy exists on disk but is not represented in the current RMAN repository. The record may have aged out of the target control file, been lost when a control file was re-created, or never have existed because an administrator produced a supported user-managed copy outside RMAN.

The RMAN CATALOG command addresses this metadata gap. It examines a supported file on disk and records information about that file in the RMAN repository. The target control file is always an RMAN repository. When the session also uses a recovery catalog, RMAN maintains the corresponding catalog metadata for the registered target database.

Cataloging a file does not create a backup, move the file, or prove that a complete recovery can succeed. It makes a recognized existing file known to RMAN so the file can be evaluated for later backup and recovery operations.

Distinguish CATALOG from recovery-catalog registration

The word catalog appears in several RMAN operations, but the operations are not interchangeable. In particular, REGISTER DATABASE does not add an individual backup file. It enrolls a target database in a recovery catalog. Lesson 2 instead focuses on the CATALOG command and existing backup files.

A recovery catalog is optional for many RMAN operations, including ordinary cataloging outside a Data Guard environment. Without a recovery catalog connection, CATALOG updates the target control-file repository. With a catalog connection, the recovery catalog provides the additional repository history and centralized metadata introduced in the preceding module.

When cataloging is useful

The need for CATALOG depends on the backup architecture and the recovery event. Typical uses include:

• recording a correctly created user-managed data file or control-file copy;
• adding archived redo logs that RMAN did not create or no longer has in its repository;
• recataloging disk backup pieces after repository records were lost or aged out;
• making valid backup files discoverable after they were copied or moved to another accessible directory;
• finding valid, unrecorded backup objects in the fast recovery area; and
• recording a disk backup transferred between hosts in a Data Guard environment.

An operating-system file is not eligible merely because it has a familiar extension or resides in a backup directory. A user-managed object must be a supported Oracle backup or copy whose identifying information RMAN can recognize. Cataloging does not transform an arbitrary file into a valid Oracle backup.

Prepare the RMAN session and files

RMAN must be connected as TARGET to the database whose files are being cataloged, and that target must be mounted or open. If the session also connects to a recovery catalog, the catalog database must be open. The Oracle server process must be able to locate and read each disk file through the path supplied to RMAN.

A dedicated target-database administrative account granted SYSBACKUP is preferable to using a general application account. The recovery-catalog owner is a separate identity. The following pattern lets RMAN request credentials without placing passwords in a command line, script, screenshot, or log:

rman

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

The service names and authentication method must be configured for the local environment. A recovery-catalog connection is included because this module teaches catalog use, but the file-cataloging operation still updates the target's RMAN repository when the session runs without one.

Identify objects that RMAN can catalog

A backup set is a logical RMAN structure containing one or more physical backup pieces. The filename form of CATALOG records backup pieces rather than a backup set as one abstract file. If a set has several pieces, catalog each piece. Until all required pieces are recorded, RMAN considers the backup set only partially available and cannot use it as a complete restore source.

Catalog individual copies, logs, and backup pieces

Begin with a specific file whenever its type and location are known. The following examples assume that each file already exists, is readable by the Oracle process, was correctly created, and belongs to the connected target database:

CATALOG DATAFILECOPY '/u03/rman/users01.dbf' LEVEL 0;
CATALOG CONTROLFILECOPY '/u03/rman/control01.ctl';
CATALOG ARCHIVELOG '/u03/rman/arch/1_731_1234567890.arc';
CATALOG BACKUPPIECE '/u03/rman/prod_bkp_01.bkp';

DATAFILECOPY records an existing data file image copy. The only valid value for its optional LEVEL clause is 0. Recording a suitable copy at level 0 allows it to serve as the base of a later incremental backup strategy. This metadata choice does not retroactively correct the procedure used to create the file.

CONTROLFILECOPY records a supported control-file copy. Oracle documents normal and standby control-file copies created through appropriate RMAN or SQL commands. ARCHIVELOG records an archived redo log. BACKUPPIECE records a disk backup piece after RMAN verifies its header, and the piece can come from a previous database incarnation.

If the command reports an identity mismatch or an invalid header, investigate the file and the target connection. Do not attempt to bypass the check or rename an unrelated file to make it appear eligible.

Discover multiple files safely

When several valid files exist beneath a known location, CATALOG START WITH can search by a strict left-side prefix:

CATALOG START WITH '/u03/rman/arch/';

The argument is not a shell wildcard or regular expression. A short prefix can match more paths than expected. By default, RMAN displays the matching candidates and asks for confirmation. It also reports files in the location that it cannot catalog. Review the prefix and the candidates before approving the operation.

After the search has been reviewed and incorporated into a controlled procedure, NOPROMPT suppresses the per-match confirmation:

CATALOG START WITH '/u03/rman/arch/' NOPROMPT;

The fast recovery area has a dedicated form:

CATALOG RECOVERY AREA;

This command searches the configured fast recovery area for valid backup sets, data file copies, and archived redo logs not currently known to the repository. CATALOG DB_RECOVERY_FILE_DEST is an exact synonym, but CATALOG RECOVERY AREA communicates the purpose more clearly.

Neither bulk form moves files, repairs corrupt content, or verifies every block. The operation discovers recognizable objects and records their metadata.

Inspect the new records and test recoverability separately

Use the LIST command that corresponds to the object just cataloged:

LIST COPY;
LIST BACKUP SUMMARY;
LIST ARCHIVELOG ALL;

The listing confirms that RMAN has a repository record. It does not establish that all blocks are readable or that every data file, control file, archived redo log, parameter file, key, and configuration item needed for the intended recovery is available.

Keep the following operations separate:

1. CATALOG records metadata for recognized existing files.
2. CROSSCHECK reconciles recorded status with files RMAN can access through the relevant storage channel.
3. VALIDATE reads database files or backups for its documented validation task.
4. A controlled restore test demonstrates whether the backup set can support the planned recovery procedure.

For a user-managed image copy, RMAN checks identifying information in the header while cataloging. It does not read every data block to search for corruption, and it does not guarantee that an operating-system utility copied an online data file correctly. A fractured or otherwise invalid copy does not become sound merely because a repository record was created.

Once a valid image copy is cataloged, RMAN can consider it for operations such as RESTORE or SWITCH. This is eligibility, not a promise that RMAN will select the copy or that recovery will succeed. Storage snapshots or broken-mirror copies must first be created under a documented Oracle procedure that protects the consistency of online data files.

Catalog disk backups in a Data Guard environment

A recovery catalog is required when RMAN manages a Data Guard environment. Primary and standby databases share a DBID but have different DB_UNIQUE_NAME values. The catalog therefore tracks both the database identity associated with a backup and the location from which that backup is accessible.

In general, tape backups can be accessible to other databases in the Data Guard environment when the media-management configuration permits it. Disk backups are normally accessible only to the database that created them. If an administrator transfers a disk backup to another host, connect as TARGET to the database on that host and catalog the transferred file there.

A backup on shared disk can require a current CHANGE ... RESET DB_UNIQUE_NAME operation to associate it with another database. That command deliberately changes Data Guard metadata and cannot be treated as a generic cataloging shortcut. Verify the exact association, physical accessibility, and 26ai syntax before using it.

Remove a stale repository record without deleting the file

If a data file copy was removed outside RMAN and its metadata should be discarded, specify the object and use UNCATALOG:

CHANGE DATAFILECOPY '/u03/rman/users01.dbf' UNCATALOG;

CHANGE ... UNCATALOG removes the recovery-catalog reference and updates the target control-file record to DELETED. It does not delete or alter the physical backup or copy. Use it when a file was deleted by a mechanism other than RMAN or when the metadata must be deliberately removed while the file remains untouched.

When the intended result is to remove both the physical file and its repository record, use a documented RMAN DELETE workflow. When a file may only be temporarily missing or inaccessible, run an appropriate CROSSCHECK, review its status, and determine the storage cause before deleting metadata.

Use a controlled cataloging workflow

1. Connect RMAN to the correct mounted or open target database and, when used, the open recovery-catalog database.
2. Confirm the target identity, file origin, storage location, and operating-system read access.
3. Choose the most specific supported CATALOG form.
4. For a backup set, ensure that every required physical piece is present and cataloged.
5. Review prefix matches before adding NOPROMPT to automation.
6. Inspect the resulting repository records with the appropriate LIST command.
7. Reconcile storage status, validate content, and perform restore tests according to the recovery plan.

This sequence keeps metadata maintenance separate from physical backup creation and recovery assurance. A catalog entry is valuable only when it accurately describes an accessible backup that fits a tested recovery procedure.

Next lesson

In the next lesson, you will examine how to protect the recovery catalog and how much repository metadata can be reconstructed if the catalog is lost. Older metadata and catalog-only objects, including stored scripts, may require normal recovery of the catalog database rather than simply recataloging surviving backup files.