Create an Oracle 26ai RMAN Recovery Catalog

A recovery catalog gives Recovery Manager (RMAN) a central place to record the backup history of your databases. This lesson takes you from an existing catalog hosting database to a working catalog schema and a registered target. You will prepare the owner, create the catalog, check the registration, and plan how to recover the catalog itself. The examples are an instructional procedure for an administrator to adapt to a lab environment; they do not represent commands already executed against your databases.

Understand the four parts of the environment

Keep four names separate while you work. The target database contains the data you intend to protect. The catalog hosting database runs the Oracle instance and stores the catalog schema. The catalog owner is a dedicated account whose objects hold recovery metadata. The backup destination contains the actual backup pieces, image copies, and archived logs. Creating a catalog creates repository objects; it does not copy the target's application data into those objects.

For example, your business database might use the service prod, while a separate catalog database exposes catdb. The account rco owns the catalog in catdb. A backup piece can reside on backup storage elsewhere. Knowing its path from the catalog helps RMAN locate it, but a catalog record cannot replace a missing or unreadable backup piece.

The target control file also contains RMAN repository information, so many ordinary backup and recovery tasks can run without a catalog. A catalog is useful when several targets share administration, when historical metadata must outlast control file records, or when you want centrally stored RMAN scripts. Plan metadata history together with physical backup retention: retaining a record longer does not make deleted backup data recoverable.

1. Prepare the catalog host and connection plan

Start with an already provisioned catalog hosting database. Oracle's current procedure calls for Enterprise Edition with Partitioning enabled. Keep the catalog outside the databases it protects and consider which failures could affect both systems. Separating schemas inside the same target does not provide independent recovery protection. Agree on storage, monitoring, and backup ownership before creating the catalog. Oracle documents these prerequisites in Managing a Recovery Catalog.

In this multitenant example, catdb resolves to a dedicated catalog PDB service in a separate hosting CDB. The owner is a local user in that PDB. The target service prod resolves to the target CDB root for whole-database administration. A service alias is a connection address, not necessarily the database name displayed by RMAN. Have the administrator verify both mappings rather than relying on a familiar-looking alias.

Prepare a small worksheet before opening either client: catalog service and PDB name, catalog owner, tablespace and quota, target service and expected DBID, backup operator, and backup storage location. Record the Oracle homes used by the catalog host and the RMAN client. For environments containing different releases, check the RMAN compatibility requirements before choosing the client or upgrading an existing catalog.

The names, file path, and sizes below are examples. Select a datafile location on the catalog database server that Oracle can create and manage. For ASM or Oracle Managed Files, use the site's storage convention instead. A path on the computer running SQL*Plus does not become a valid server datafile location merely because the client can access it.

2. Create the tablespace and catalog owner

Use SQL*Plus from the catalog hosting Oracle home. Connect as an authorized administrator to the catalog PDB service and check the container before changing anything:

sqlplus /nolog

SQL> CONNECT SYS@catdb AS SYSDBA
SQL> SHOW CON_NAME

Enter the administrator password when prompted. Confirm that the displayed container is the intended catalog PDB. If it is the root or an unexpected PDB, stop and correct the service mapping. Creating a local user requires the proper PDB context; adding a common-user prefix is not a substitute for choosing the correct container. See Oracle's CREATE USER reference for container and account rules.

Create a dedicated tablespace and a bounded starting quota. The sample file begins at 100 MB and can grow to 1 GB. These values demonstrate a configuration, not a capacity recommendation for every site:

CREATE TABLESPACE cattbs
  DATAFILE '/catalog-data/cattbs01.dbf' SIZE 100M
  AUTOEXTEND ON NEXT 10M MAXSIZE 1G;

CREATE USER rco IDENTIFIED BY "REPLACE_WITH_UNIQUE_SECRET"
  DEFAULT TABLESPACE cattbs
  TEMPORARY TABLESPACE temp
  QUOTA 1G ON cattbs;

GRANT RECOVERY_CATALOG_OWNER TO rco;

Replace the password placeholder before execution and verify that temp exists in this PDB. Choose a secret that satisfies the site's password policy. Avoid storing actual passwords in shared teaching scripts or routine logs. The account's default tablespace determines where the catalog objects will be created unless you explicitly select another tablespace.

A quota controls how much space the owner can allocate; it does not reserve that space in advance. A tablespace growth limit also does not guarantee that the storage device has free capacity. Monitor both. Estimate growth from target count, backup frequency, archived redo volume, and metadata history, then adjust the quota and storage limits through your normal administration process. Oracle's CREATE TABLESPACE reference explains datafile creation options.

While still connected as the catalog administrator, run the catalog hosting home's supplied privilege script:

@?/rdbms/admin/dbmsrmansys.sql

In SQL*Plus, ? expands to the local Oracle home. Therefore, use the appropriate catalog hosting home, or substitute its verified full script path. Review the script output for errors before proceeding. Granting RECOVERY_CATALOG_OWNER alone does not replace this documented preparation step. Do not solve a missing privilege by giving the owner the broad DBA role. The preparation and required script are described in the CREATE CATALOG reference.

3. Create the catalog objects with RMAN

Exit SQL*Plus and start the appropriate RMAN executable from your operating system terminal. Supply the account and service without placing the password in the command line:

rman CATALOG rco@catdb

RMAN> CREATE CATALOG;

RMAN prompts for the catalog owner's password. The hosting database and catalog PDB must be open. A target connection is unnecessary at this stage because you are creating the repository, not registering a business database. Allow the command to finish and inspect the result rather than assuming an apparently idle console means it failed.

The default tablespace in the preceding example is cattbs. If you need to choose it explicitly, the alternative creation command is CREATE CATALOG TABLESPACE cattbs;. Choose one creation form. Do not run the second form after a successful first command as though it adds a separate component.

To inspect the newly created objects, reconnect through SQL*Plus as rco and query its own schema:

sqlplus /nolog

SQL> CONNECT rco@catdb
SQL> SELECT table_name FROM user_tables ORDER BY table_name;

Use the returned object names as evidence of schema creation, alongside the RMAN completion log. Do not edit catalog tables directly. If creation reports an error, retain the full error stack and investigate connection context, privileges, quota, and the supplied setup script before trying again. An existing catalog should be maintained or upgraded through the supported procedure rather than dropped and recreated as a troubleshooting shortcut.

4. Register the intended target database

Catalog creation and target registration are separate milestones. Before registration, the catalog knows nothing about this target's backup history. Use an account authorized for backup administration on the target. In this example, the common user c##backup_admin already has the required SYSBACKUP privilege and authentication configuration; creating that operator is a separate administrator task. Oracle's CONNECT reference explains whole-CDB connection privileges.

rman

RMAN> CONNECT TARGET "c##backup_admin@prod AS SYSBACKUP";
RMAN> CONNECT CATALOG rco@catdb;
RMAN> REGISTER DATABASE;
RMAN> REPORT SCHEMA;
RMAN> LIST INCARNATION;

Provide each password at its prompt. Confirm the target name and DBID reported by the connection before registration. The target must be mounted or open, and the catalog must be open. If a required database is unavailable, have its administrator bring it to the appropriate state; do not issue startup or shutdown commands blindly against a service whose identity has not been checked.

REGISTER DATABASE; registers the connected target and begins catalog synchronization. It takes no target-name argument in this procedure. REPORT SCHEMA; lets you check the expected datafiles and tablespaces; LIST INCARNATION; shows incarnation records. Compare those results with the target worksheet. An incarnation records a database's recovery history across operations such as opening with RESETLOGS; it is not a separate service login.

If registration says the database is already registered, verify the existing entry rather than attempting to create a duplicate. Independently managed targets normally need distinct DBIDs. A copied database can retain its source DBID, so a naming change alone may not resolve a collision. Follow a planned clone and identity procedure instead of changing a production DBID during catalog setup. Oracle's REGISTER DATABASE reference describes registration requirements and the 26ai standby exception.

5. Check the catalog and understand synchronization

As the catalog owner in SQL*Plus, list the registered database identities through the documented catalog view:

SELECT db_key, dbid, name
FROM rc_database
ORDER BY name, dbid;

The DBID identifies the database; DB_KEY is its catalog key. Match the expected DBID rather than treating a matching display name as sufficient evidence. The RC_DATABASE view reference describes these columns. Run this query against the catalog schema, not the target's application schema.

For routine inspection in an RMAN session connected to both systems, use:

RMAN> LIST BACKUP SUMMARY;
RMAN> SHOW ALL;
RMAN> RESYNC CATALOG;

A newly registered lab target may have no recorded backups. Registration does not create one, so an empty backup list can be a valid result. SHOW ALL; displays the connected target's persistent RMAN configuration. Review it before proceeding to the next lesson's backup script. The LIST reference provides the supported reporting forms.

Resynchronization refreshes catalog metadata from the target repository. RMAN normally performs needed synchronization during its work; the explicit command is useful when you deliberately want a refresh. It does not recover deleted backup pieces or copy records between arbitrary independent catalog databases. It also cannot retrieve historical records that have already disappeared from the available control file. See RESYNC CATALOG.

Snapshot control files and concurrent RMAN sessions

RMAN uses a snapshot control file to obtain a consistent control file view for operations that require one. Inspect the configured location with:

RMAN> SHOW SNAPSHOT CONTROLFILE NAME;

The snapshot file supports RMAN's metadata work. It does not replace a recoverable control file backup. In RAC, its storage must be accessible to the relevant instances. Do not change the filename simply to suppress a symptom without checking the storage and instance requirements.

RMAN coordinates snapshot control file access with an enqueue. A waiting session can indicate another operation holds that enqueue. Oracle's ORA-00230 explanation describes that contention. There is no catalog setup step involving SQL commands named CREATE SEMAPHORE, ACQUIRE, or RELEASE. Investigate the active RMAN work and storage access using normal diagnosis rather than adding an invented locking script.

6. Protect the catalog database

Treat catalog availability as part of the recovery plan. Assign someone to monitor its backups, available storage, credentials, and restoration procedure. A working catalog can still be lost through a host failure or an administrative mistake. Decide how its hosting CDB and catalog PDB will be recovered before making the repository an operational dependency.

One practical approach is to back up the separate catalog hosting database through its own control file repository, without depending on the catalog being backed up. On that host, with the intended catalog hosting CDB selected and appropriate operating system authorization, a lab example is:

rman TARGET / NOCATALOG

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

The slash connection selects the local database through the configured environment. Verify that it is the catalog hosting CDB, not the business target. The backup example assumes an appropriate ARCHIVELOG configuration, usable backup destination, and sufficient space. Set those prerequisites through the site's backup policy before execution. Oracle documents control file autobackups in Configuring the RMAN Environment.

Keep the hosting database DBID, backup locations, control file autobackup information, encryption or wallet dependencies, and recovery instructions independently accessible. Test restoration in an isolated environment and verify that the restored catalog can be queried and used. A successful backup job is one piece of evidence; an exercised recovery procedure demonstrates that the people and dependencies needed during an outage are available.

Oracle 26ai behavior and lesson completion

Oracle 26ai permits explicit physical standby registration and full catalog resynchronization using a standby control file, subject to documented limitations. Primary and standby identity handling differs from unrelated targets: Data Guard databases share a DBID and use distinct DB_UNIQUE_NAME values. Oracle also releases catalog connections while a target backup runs. These changes are covered in the 26ai recovery catalog guide; they do not introduce different creation syntax for this lesson's ordinary primary target.

Before leaving the lab, retain evidence of the catalog container, owner preparation, successful creation, registered target DBID, schema report, incarnation report, and catalog protection plan. Record any unresolved errors instead of marking a partially completed setup as ready. You now have the repository foundation for the next lesson, creating backup scripts. That lesson applies backup policy and commands to produce the physical backups the catalog will track.