Create an Oracle RMAN Recovery Catalog

Recovery Manager can back up and recover an Oracle database without a recovery catalog. In that configuration, RMAN uses repository metadata in the target database control file. A recovery catalog adds a second, centralized repository that can preserve longer history, store RMAN scripts, and report across registered databases. It is also required when RMAN manages databases in an Oracle Data Guard environment.

This lesson implements the catalog design introduced in Lesson 8. The procedure creates a base recovery catalog in a dedicated schema, verifies its objects and schema version, registers one target CDB, and confirms that RMAN can read the registered metadata. Creating a catalog does not create a database backup, copy application data, or replace the repository in the target control file.

The examples use the following names consistently. Replace every service name, path, size, user name, and password token with values approved for your environment. Test the complete procedure outside production before adopting it in an operational runbook.

Component	Example	Purpose
Catalog PDB and service	CATPDB and catpdb	Hosts and exposes the recovery catalog schema
Catalog tablespace	rcat_ts	Stores catalog-owned objects
Catalog owner	rco	Owns the base recovery catalog
Target service	prodcdb	Identifies the target CDB to register
Target operator	backup_admin	Connects to the target with SYSBACKUP

Three identities appear in this workflow because they perform different jobs. The catalog database administrator creates storage, creates the owner, grants RECOVERY_CATALOG_OWNER, and runs Oracle's supporting script. The catalog owner connects through RMAN to create and own the catalog objects. The target operator connects to the protected database with SYSBACKUP so RMAN can read and update target repository metadata.

Do not collapse these duties into one permanently powerful account for convenience. The catalog owner does not need SYSDBA on the catalog database, and it does not need administrative authority on every registered target. The target operator does not need to own catalog tables. A DBA may perform more than one role during a controlled installation, but the connection privileges should still reflect the task being performed.

The catalog owner's password and each target administrative credential should be managed through the organization's privileged-access controls. Allow RMAN or SQL*Plus to prompt when demonstrating an interactive connection. For automation, use an approved external password store or another supported credential mechanism. Avoid command lines, parameter files, scripts, job output, and shell history that expose reusable credentials.

This separation also improves auditing. Catalog schema changes can be distinguished from target backup activity, and the account used by a scheduler can be limited to its documented RMAN operations. Before implementation, record who owns each credential, how it is rotated, which services it may reach, and how administrators regain access during a recovery incident.

A base recovery catalog is a schema in an Oracle database. Do not place a target database's catalog inside that same target database. A failure that makes the target unavailable could also remove the metadata needed to locate and interpret its backups. A dedicated catalog database is the clearest design, but Oracle does not require a separate physical server in every case. Select hosts, storage, regions, and administrative boundaries from the organization's documented failure analysis.

For Oracle AI Database 26ai, the catalog database must use Oracle Database Enterprise Edition with Oracle Partitioning enabled. The database or PDB that contains the catalog schema must be open and reachable through a service. Oracle recommends running the catalog database in ARCHIVELOG mode, particularly when its recovery plan includes point-in-time recovery. The catalog requires independent backup, monitoring, patching, and recovery procedures.

Compatibility involves several versions, not one. For a 26ai target, use the RMAN executable from that target's Oracle home. The RMAN client must match the target database executable, and an auxiliary database used by the same operation must match the client. The catalog database can be Oracle Database 12.1 or later with COMPATIBLE set to at least 12.1. The recovery catalog schema version must be greater than or equal to the RMAN client version. Check the current compatibility matrix before one catalog manages a mixture of database releases.

Catalog capacity depends on the number of targets, data files, archived logs, backup pieces, stored scripts, RMAN operations, and retained history. Oracle's planning examples illustrate that an ordinary registered database may consume about 15 MB of catalog schema space per year, while a busy environment can require substantially more. Treat that figure as an estimate, not a quota. Monitor growth and include ordinary database overhead such as SYSTEM, SYSAUX, undo, temporary space, online redo, diagnostics, and backups.

Complete a preflight readiness review

Resolve the following items before creating catalog objects. This prevents a partly configured schema from becoming the point where storage, networking, authentication, or version problems are first discovered.

1. Confirm that the catalog host uses Enterprise Edition with Partitioning enabled. Record the database release, the COMPATIBLE setting, and the RMAN client version that will create the catalog schema.
2. Confirm that the intended catalog PDB is open and that catpdb resolves to that PDB. Test listener reachability and service registration from the host where RMAN will run. A successful connection to the wrong container is still a configuration error.
3. Confirm that the target service prodcdb resolves to the intended CDB and that backup_admin can authenticate with SYSBACKUP. Record the target database name, DBID, and DB_UNIQUE_NAME before registration.
4. Confirm that the catalog tablespace can be created in the approved storage destination and that monitoring covers both allocated space and the underlying filesystem or ASM disk group. Autoextension does not remove the need to monitor destination capacity.
5. Confirm that the catalog database has its own backup destination and recovery procedure. The catalog should not depend on the catalog it contains, and its backups should not share every failure mode with the targets it protects.

Capture these facts in the operational record before running SQL. If a value changes later, especially a service, DBID, Oracle home, or catalog schema version, update the runbook and verify the supported transition rather than assuming that the original installation commands still apply.

Perform the next tasks as a catalog database administrator. In a multitenant database, make sure the session is in the PDB intended to contain the catalog. The following local operating-system authentication example switches to CATPDB and verifies the current container. A remote administrator should instead use the organization's approved secure administrative connection.

sqlplus / as sysdba

ALTER SESSION SET CONTAINER = CATPDB;

SELECT SYS_CONTEXT('USERENV', 'CON_NAME') AS current_container
FROM   dual;

Do not continue if the query reports CDB$ROOT or another unintended container. The catalog owner should be a dedicated local account in the selected PDB, not a common administrative account in the root.

Create a dedicated tablespace. This representative example uses a filesystem-managed data file. An installation that uses Oracle Managed Files or Oracle ASM should follow its configured storage conventions instead of copying this pathname. A controlled maximum and capacity alerting are usually safer than unmonitored unlimited growth.

CREATE TABLESPACE rcat_ts
  DATAFILE '/u02/oradata/catdb/rcat01.dbf'
  SIZE 500M
  AUTOEXTEND ON NEXT 100M
  MAXSIZE 4G;

Create the owner, grant the catalog role, and install the additional privileges required by that role. In the example, your_secure_password is a replacement token. Do not use it literally, publish a real credential, or place a password in shell history. The catalog owner must not be SYS, SYSBACKUP, or another privileged administrative schema.

CREATE USER rco IDENTIFIED BY your_secure_password
  DEFAULT TABLESPACE rcat_ts
  TEMPORARY TABLESPACE temp
  QUOTA UNLIMITED ON rcat_ts;

GRANT RECOVERY_CATALOG_OWNER TO rco;

@?/rdbms/admin/dbmsrmansys.sql

Run dbmsrmansys.sql as an administrator from the Oracle home of the catalog database. The SQL*Plus question-mark notation resolves that Oracle home without embedding a platform-specific path. Do not run the obsolete catrman.sql script. Also, do not grant the catalog owner the legacy CONNECT or RESOURCE roles, SYSDBA, SELECT ANY DICTIONARY, or target-database privileges merely to create a base catalog.

Start the RMAN client from the Oracle home that matches the 26ai target. Connect to the catalog service as its owner and allow RMAN to prompt for the password. A target connection is not required while the catalog objects are being created.

rman CATALOG rco@catpdb

RMAN> CREATE CATALOG;

Because rcat_ts is the owner's default tablespace, CREATE CATALOG creates the catalog objects there. When an explicit destination is required, RMAN also supports CREATE CATALOG TABLESPACE rcat_ts. Use one method deliberately rather than depending on an accidental default. Catalog creation can take several minutes, so review the complete RMAN result before treating the operation as successful.

A successful login proves only that the account and service work. Verify the schema separately. Connect to catpdb as rco, then query the catalog version and owned tables.

SELECT *
FROM   rcver;

SELECT table_name
FROM   user_tables
ORDER  BY table_name;

The RCVER view identifies the recovery catalog schema version. It does not report the catalog database release. This distinction matters when a catalog manages several target releases because the catalog database and catalog schema follow different compatibility rules. The USER_TABLES query confirms that catalog objects exist in the expected owner schema.

Registration enrolls a target in the catalog and copies relevant repository metadata from its control file. It does not copy data files, archived redo logs, backup pieces, or application data. Before registration, the catalog database must be open, the target must be mounted or open, and the target must not already be registered in this catalog.

Use separate identities for the two connections. The dedicated catalog owner connects to catpdb. A target operator with the administrative privilege SYSBACKUP connects to prodcdb. Grant SYSBACKUP through the site's normal privileged-account process, and keep both credentials out of the command line.

rman TARGET "backup_admin@prodcdb AS SYSBACKUP" CATALOG rco@catpdb

RMAN> REGISTER DATABASE;

RMAN records the target, imports repository information from its control file, and performs an initial full catalog resynchronization. An ordinary registered target must have a unique database identifier, or DBID. Different targets can share a database name when their DBIDs differ. If an unsupported file copy has produced duplicate DBIDs, correct the identity with the appropriate controlled database procedure before attempting to register both databases. Changing a DBID is not a routine catalog-creation step.

Remain connected to the target and catalog, then run repository reports. Oracle documents REPORT SCHEMA as the immediate verification after registration. The additional commands confirm the target identity, incarnations, and persistent RMAN configuration.

RMAN> REPORT SCHEMA;
RMAN> LIST INCARNATION;
RMAN> SHOW ALL;

Observation	What it establishes
CREATE CATALOG completes	The base catalog objects were created for rco
RCVER returns a row	The catalog exposes its schema version
REGISTER DATABASE reports a full resynchronization	The target was registered and its control-file metadata was synchronized
REPORT SCHEMA lists the expected structure	RMAN can read the registered target metadata
SHOW ALL displays expected settings	The connected repository exposes the target's persistent RMAN configuration

These checks verify the catalog workflow, but they do not prove that backup media is readable or that the recovery objectives can be met. After the catalog is validated, run the organization's approved backup job and perform a restore or recovery test in an isolated environment. Do not use an unreviewed BACKUP DATABASE command as the first and only proof that catalog creation succeeded.

Diagnose the workflow at its phase boundaries

When a step fails, diagnose that phase before repeating later commands. Reissuing the entire procedure can hide the original condition and may create confusing partial results.

1. If the owner cannot connect to catpdb, verify the service, current PDB state, account status, authentication method, and network path. Do not grant broader database privileges as a substitute for fixing connectivity or account configuration.
2. If CREATE CATALOG fails, retain the RMAN and database errors. Confirm the owner role, execution of dbmsrmansys.sql, default tablespace, quota, free space, catalog database edition, Partitioning availability, and version compatibility. Determine whether catalog objects were created before retrying or cleaning up.
3. If RCVER or USER_TABLES returns an unexpected result, verify that SQL*Plus is connected as rco to the correct PDB. Do not interpret objects in another owner or container as proof that this catalog exists.
4. If REGISTER DATABASE reports that the target is already registered, stop and identify the existing catalog entry. Do not unregister a database merely to make the command succeed. Registration history may be needed for valid backups and recovery operations.
5. If registration reports a duplicate DBID, identify how the databases were created and which identity is authoritative. Resolve duplicate identity through a separately reviewed database procedure. Never improvise a DBID change during catalog installation.
6. If registration succeeds but REPORT SCHEMA shows an unexpected database, compare the connected target service, DBID, database name, DB_UNIQUE_NAME, and container context with the preflight record. Disconnect before making any configuration changes.

Save the successful command transcripts and verification results with the catalog build record, but remove passwords and other secrets. Those records provide a baseline for later upgrades, registration reviews, and incident response.

Primary and physical standby databases in a Data Guard environment share a DBID and database name. Their distinct DB_UNIQUE_NAME values identify the individual physical databases. Oracle AI Database 26ai allows REGISTER DATABASE while RMAN is connected as TARGET to either the primary or a physical standby database.

When connected to a physical standby, RMAN can explicitly register it and 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 depends on correct Data Guard connect identifiers, so it belongs in a Data Guard runbook rather than the basic single-target procedure shown here.

RMAN normally resynchronizes catalog metadata automatically during operations while both the target and catalog are connected. Use RESYNC CATALOG when a documented condition requires a manual resynchronization, not as an automatic command before every backup. Monitor resynchronization failures, schema-space growth, service availability, backup metadata, and catalog version compatibility.

The catalog database must have a recoverable backup independent of the catalog it hosts. Back it up while RMAN is connected to the catalog database as the target in NOCATALOG mode. The following local example uses operating-system authentication with the SYSBACKUP privilege. Adapt the backup command, destination, encryption, retention policy, and archived-log handling to the approved catalog-database protection plan.

rman

RMAN> CONNECT TARGET "/ AS SYSBACKUP";
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Keep the catalog database's control-file autobackups, configuration records, connection information, and recovery instructions in a protected location. Test recovery of the catalog database itself. A catalog that contains years of backup history is valuable only when administrators can restore it during the same incident that affects a protected target.

Do not remove catalog records simply because RMAN reports them as expired. EXPIRED means that a crosscheck could not find the associated file at its recorded location; it does not by itself authorize deletion. Investigate storage and media-management state, apply the organization's retention policy, and distinguish obsolete backups from temporarily inaccessible media before changing repository records.

The base catalog and target are now ready for catalog-aware RMAN operations. Later administration may include catalog upgrades, virtual private catalogs, stored scripts, catalog imports, and controlled target removal. Those activities build on the verified owner, catalog objects, registration, and protection workflow completed in this lesson.