Start RMAN with a Recovery Catalog

Lesson 1 distinguished the target control-file repository from the recovery catalog and explained why connection scope must be verified before a repository-dependent command runs. This lesson applies that rule. You will prepare the RMAN client environment, verify two Oracle Net services, connect with two different identities, and confirm that RMAN reached the intended target CDB and catalog PDB.

Starting the rman executable and connecting to databases are separate actions. The target connection gives RMAN administrative access to the database whose files and repository metadata it will manage. The catalog connection authenticates the owner of a separate schema containing synchronized RMAN metadata. The catalog owner does not need target administrative privileges, and the target operator does not own the catalog.

The examples do not contain passwords. RMAN prompts for credentials when required. This prevents a published command from teaching credentials that can be exposed through command history, process listings, scripts, screenshots, scheduler definitions, or diagnostic collections.

The following names continue the example introduced in Module 3. Replace them with approved values from the operational record. The service names must identify different database roles even if network routing happens to pass through the same host or listener.

Example RMAN target and catalog identities

Component	Example	Expected scope
RMAN client	Target database Oracle home	Client selected for the Oracle 26ai target
Target service	prodcdb	Target CDB root
Target operator	backup_admin	Common account granted SYSBACKUP
Catalog service	catpdb	PDB containing the base recovery catalog
Catalog owner	rco	Dedicated owner of the catalog schema

backup_admin is a readable placeholder. The deployed common-user name must comply with the site's COMMON_USER_PREFIX setting, which commonly results in a name such as C##BACKUP_ADMIN under the default configuration. The account must be common because this example connects to the CDB root for CDB-wide work. A PDB-scoped operation can use other documented connection models, but it does not silently grant authority over the entire CDB.

The catalog service must lead to the PDB containing rco. Connecting successfully to CDB$ROOT, a different PDB, a standby with the wrong DB_UNIQUE_NAME, or another catalog database is not a partial success. It is the wrong connection and should stop the session.

A host can contain several Oracle homes. Verify which executable the operating system will start, then read the RMAN startup banner to confirm the client release. The client, target, auxiliary, catalog database, and catalog schema have distinct compatibility rules. Do not assume that the first rman on PATH is appropriate merely because it starts.

On Linux or Unix, load the approved target environment and identify the executable:

. oraenv
command -v rman
rman

On Windows, verify the search result before starting RMAN:

where rman
rman

Read the banner, compare it with the target environment and supported compatibility matrix, and use EXIT if this is only a preflight check. Do not hard-code an installation directory or a release-specific executable name.

Test both connect identifiers from the same host and Oracle Net environment that RMAN will use. An alias that works from a database server can fail from a scheduler or administration host because it reads a different naming configuration, wallet, directory service, or Oracle home.

tnsping prodcdb
tnsping catpdb

TNSPING tests whether a connect identifier can be resolved and whether the associated listener can be reached. It does not prove that the database or PDB is open, that the requested service is usable, that an account can authenticate, or that the service reaches the expected container. Only an authenticated database connection supplies that end-to-end evidence.

When a service is missing or reports a handler problem, inspect the listener on the appropriate server:

lsnrctl status
lsnrctl services

STATUS summarizes the listener configuration and registered service names. SERVICES provides service, instance, and handler detail. Dynamic registration through the database Listener Registration process, LREG, is the normal model. A modern listener.ora is not a manual inventory of every CDB and PDB service.

If prodcdb or catpdb is absent, verify the database and PDB state, service configuration, LREG endpoints, listener addresses, cluster resources, and the client connect descriptor. Listener logs in the Automatic Diagnostic Repository can show service_register, service_update, and service_died events. Diagnose the configuration actually in use rather than editing every sqlnet.ora, tnsnames.ora, or listener.ora file found on the host.

Oracle 26ai provides the following current command-line options. The complete syntax is defined in the RMAN Reference, while the options most relevant to this module are summarized here.

Current RMAN startup options

Option	Purpose	Operational guidance
TARGET	Connects to the database whose files and repository RMAN manages	Use the intended target service and an approved administrative identity
CATALOG	Connects to the schema that owns the recovery catalog	Use the catalog owner and service, then allow RMAN to prompt for its password
NOCATALOG	Uses the target control file without a recovery catalog	Lesson 3 presents this mode
AUXILIARY	Connects to an auxiliary database	Used by duplication and selected recovery workflows, not this connection
CMDFILE or @	Parses and executes an RMAN command file	Use a reviewed file that contains no credentials
LOG	Writes RMAN commands and results to a log file	Protect the file and verify that RMAN could open it
APPEND	Appends output to an existing RMAN log	Without it, an existing file of the same name is overwritten
CHECKSYNTAX	Parses commands without executing them	Checks syntax, not connectivity, authorization, or recoverability

RMAN option names are case-insensitive, but uppercase improves the readability of syntax explanations. File-name quoting and command-line quoting are handled by the operating-system shell as well as RMAN, so a single Windows or Unix example should not be presented as universal.

The RMAN prompt provides the clearest cross-platform procedure. It lets the operator verify the target before connecting to the catalog and prevents passwords from appearing in the operating-system command line.

rman

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

RMAN prompts separately for the target and catalog passwords. The quotation marks around the target connection are required because the string includes AS SYSBACKUP. If neither AS SYSBACKUP nor AS SYSDBA is specified, RMAN defaults the target connection to AS SYSDBA. Omitting the privilege therefore does not select the narrower backup-specific privilege.

The target account must have the selected administrative privilege and a usable authentication path. Password-file authentication permits an authorized account to connect when the target is not open, which is necessary for many restore and recovery operations. The password file must support SYSBACKUP, and the service must reach the intended root when the operation covers the CDB.

The catalog owner authenticates as the ordinary schema account rco. Do not add AS SYSBACKUP or AS SYSDBA to the catalog connection, and do not grant those privileges merely so the schema can be used as an RMAN catalog. The catalog owner and target operator have different responsibilities even if one administrator controls both credentials.

When RMAN runs on the target database host, an operating-system account in the authorized backup-administration group can connect locally without a target password. Specify the intended privilege rather than relying on an implicit default:

rman

RMAN> CONNECT TARGET "/ AS SYSBACKUP";
RMAN> CONNECT CATALOG rco@catpdb;

The first command requires operating-system authorization for SYSBACKUP, commonly through the platform's OSBACKUPDBA group. If the account has only OSDBA authorization, TARGET / connects implicitly as SYSDBA. The slash does not universally mean SYSBACKUP.

Local authentication applies to the target in this example. The catalog remains a separate connection through catpdb and authenticates as rco. Do not place a target database's recovery catalog inside that same target merely to make both connections local. A shared database failure could remove the target and the extended metadata intended to help recover it.

An operator can establish both connections from the operating-system command line. The following quoting is a Linux or Unix shell example:

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

Windows Command Prompt and PowerShell interpret quotation marks differently, so the prompt-based method is the more portable teaching form. RMAN still prompts for both passwords because neither credential is included. Never publish or automate a connection string that embeds a username and password. A secret on a command line can remain visible after the RMAN session ends.

Read the complete RMAN connection messages before issuing a command that creates, changes, catalogs, crosschecks, or deletes anything. The target message identifies the database name and DBID. Compare both values with the approved operational record. In a Data Guard environment, also confirm the expected DB_UNIQUE_NAME and database role rather than assuming that a shared DBID identifies the intended physical database.

The catalog connection should report that RMAN connected to the recovery catalog database. Confirm that catpdb leads to the intended PDB and that rco owns the expected base catalog. A successful catalog login does not prove that the target is registered in that catalog.

Use read-only commands as a second identity check:

RMAN> REPORT SCHEMA;
RMAN> SHOW ALL;

REPORT SCHEMA should describe the expected target database structure. SHOW ALL displays persistent RMAN configuration for the connected target. Unexpected data is a stop condition. Disconnect and correct the service, container, account, or catalog before continuing.

These commands verify repository context, not backup quality. They do not prove that backup media is accessible, that encrypted backups can be decrypted, or that the recovery point and recovery time objectives can be met. Validation and isolated recovery exercises provide different evidence.

Before executing a reviewed command file, RMAN can parse it without running its commands. The following path is an example and must be replaced with a protected site-specific location:

rman CHECKSYNTAX CMDFILE=/opt/oracle/rman/check-target.rman

A successful syntax check means that RMAN parsed the file. It says nothing about service reachability, authentication, database state, target identity, authorization, storage availability, or recoverability.

An interactive catalog-aware job can combine a command file and log after the authentication method is approved:

rman TARGET / CATALOG rco@catpdb \
  CMDFILE=/opt/oracle/rman/report-target.rman \
  LOG=/var/log/oracle/rman/report-target.log

Do not put the catalog password in the command file. For unattended jobs, use a supported, approved credential mechanism rather than an interactive prompt or embedded secret. If RMAN cannot open the specified log, it writes to standard output instead of terminating, so the scheduler must capture and alert on that condition.

The APPEND option appends to an existing RMAN log; otherwise RMAN overwrites a file of the same name. Logs can contain database names, DBIDs, backup locations, media-manager messages, and error details. Apply controlled ownership, permissions, retention, rotation, monitoring, and redaction.

Do not respond to every Oracle Net error by editing configuration files. Preserve the complete error stack and identify the layer that failed. A successful lower-layer check does not prove that the next layer works.

RMAN connection troubleshooting boundaries

Boundary	Initial interpretation	First verification
Name cannot be resolved	The client cannot resolve the connect identifier	Naming method, active configuration location, and exact service spelling
No listener	The resolved address has no reachable listener	Host, port, listener state, network route, and firewall
Service not registered	The listener does not know the requested service	PDB or service state, LREG, listener endpoints, and cluster resources
Authentication failure	The database rejected the identity	Account state, privilege, password file, container, and credential source
Wrong target identity	The connection reached an unintended database or container	Service definition, database name, DBID, DB_UNIQUE_NAME, and container

A useful diagnostic sequence is: confirm the RMAN executable and Oracle Net environment, resolve each service, check listener reachability, inspect registered services and handlers, verify database and PDB state, perform authenticated connections, then review RMAN's identity output. Use ADR logs and tracing when the error remains unresolved.

This sequence replaces the legacy Oracle 8 listener transcript. Modern troubleshooting should not depend on a particular listener version string, Windows path, default domain suffix, static SID list, or screenshot. It should establish which component rejected the connection and why.

Do not validate startup by expecting a fixed number of processes. The RMAN client parses commands and coordinates operations. A target connection creates a database session to the target, and a catalog connection creates a separate session to the catalog database. The platform may implement database execution through processes or threads.

When backup, restore, or recovery work begins, RMAN channels correspond to target or auxiliary database server sessions that perform I/O through a device type such as DISK or SBT. Automatic channels can be configured persistently, while manual channels can be allocated in a RUN block. Channel allocation is separate from the proof that the initial target and catalog identities are correct.

Oracle Enterprise Manager can orchestrate RMAN work, but a graphical interface does not replace these connection, privilege, service, repository, and verification rules. The legacy name Backup Manager should not be presented as a current standalone RMAN component.

1. Verify the RMAN executable and client release selected for the target environment.
2. Confirm that prodcdb resolves to the target CDB root and catpdb resolves to the catalog PDB.
3. Confirm that the target identity uses the intended SYSBACKUP or approved SYSDBA privilege.
4. Confirm that the catalog connection authenticates as rco, not as a privileged database administrator.
5. Keep passwords out of command-line arguments, command files, logs, screenshots, and job output.
6. Compare the connected target database name, DBID, and Data Guard identity with the approved record.
7. Review REPORT SCHEMA and SHOW ALL before any command that changes data, configuration, or repository metadata.
8. Retain a protected, secret-free transcript that records successful connection and identity verification.

The session is now ready for catalog-aware RMAN work. Lesson 3 will start RMAN explicitly in NOCATALOG mode and explain how the target control file becomes the exclusive RMAN repository for that session.