Start RMAN Without a Recovery Catalog

Lesson 2 started RMAN with separate target and recovery-catalog connections. This lesson demonstrates the deliberate alternative. RMAN connects to the target database but does not connect to a recovery catalog. The target control file becomes the exclusive RMAN repository available to that client session.

The option name NOCATALOG does not mean that RMAN has no repository. RMAN still records backup, copy, archived redo log, incarnation, and configuration metadata in the target control file. The difference is repository reach. RMAN cannot use catalog stored scripts, catalog-only history, virtual private catalogs, or a centralized catalog view of multiple registered databases during that session.

The examples use explicit repository selection and contain no passwords. Local operating-system authentication is shown with the task-specific SYSBACKUP privilege. The remote example uses a designated administrative account and lets RMAN request its password. These practices make the connection intent visible without exposing credentials in shell history, process listings, scripts, screenshots, or logs.

Both modes require a target connection. A catalog-aware session adds a connection to the schema that owns the recovery catalog. A NOCATALOG session does not make that second connection.

RMAN repository modes

Session mode	Target connection	Catalog connection	Repository available to RMAN
Catalog-aware	Required	Required	Target control file plus recovery catalog
NOCATALOG	Required	None	Target control file only

RMAN can default to NOCATALOG mode. If neither CATALOG nor NOCATALOG was specified, no CONNECT CATALOG command was issued, and an operation first requires the repository, RMAN selects NOCATALOG at that point. This lesson specifies the option at startup so that the operator, job record, and log all show the intended repository mode before work begins.

Repository selection also creates a session boundary. After a command has used the RMAN repository in NOCATALOG mode, you must exit and restart RMAN before connecting to a recovery catalog. Do not begin control-file-only work and then attempt to attach a catalog to the same repository session.

The following examples continue the environment used in the preceding lessons. Replace every example value with an approved value from the target's runbook or change record.

Example target environment

Component	Example	Meaning
Local instance	PRODCDB1	Instance selected by ORACLE_SID on the database server
Target database	PRODCDB	CDB whose control file contains the RMAN repository
Target service	prodcdb	Oracle Net service that reaches the target CDB root
Target operator	backup_admin	Common administrative user granted SYSBACKUP

backup_admin is a readable placeholder. A deployed common-user name must comply with the database's COMMON_USER_PREFIX setting. With the usual default, a site might use a name such as C##BACKUP_ADMIN. The account is common in this example because it connects to the root for CDB-wide work.

An SID, database name, and service name are not interchangeable. ORACLE_SID selects a local database instance. It does not identify a PDB or a remote database. An Oracle Net connect identifier such as prodcdb resolves to a connect descriptor whose service must reach the intended database and container.

For local operating-system authentication, first select the target instance and the correct Oracle home. A server can contain multiple homes, and the first rman executable on PATH may belong to a different installation.

On Linux or Unix, use the site's approved environment procedure and identify the selected executable:

. oraenv
command -v rman

When oraenv requests an SID, enter the local target instance, such as PRODCDB1. On Windows, select the instance and inspect the executable found through PATH:

set ORACLE_SID=PRODCDB1
where rman

Read the RMAN startup banner and verify the client release. The environment commands above are examples, not substitutes for a site's approved Oracle-home, cluster, service, or scheduler configuration. A remote connection does not use the client host's ORACLE_SID to select the target. It uses Oracle Net Services.

The most portable teaching sequence starts the client and then makes the target connection at the RMAN prompt. This separates repository selection from authentication and avoids operating-system shell quoting differences.

rman NOCATALOG

At the RMAN prompt, connect to the local CDB root using operating-system authentication and explicitly request SYSBACKUP:

CONNECT TARGET "/ AS SYSBACKUP";

The operating-system account must be authorized for this privilege, normally through the installation-defined OSBACKUPDBA group. On Linux and Unix, that group is commonly named backupdba, but the actual name is selected during installation. An account authorized through OSDBA can connect with SYSDBA instead.

The slash does not pass the operating-system account's username and password to Oracle. It requests external operating-system authentication. Oracle uses the local instance environment and authorized group membership to establish the administrative database session. Operating-system authentication is local; use password-file authentication for a remote target.

If the privilege is omitted, CONNECT TARGET / defaults to AS SYSDBA. It does not default to the narrower SYSBACKUP privilege. Explicit privilege text makes the intended authority visible during review.

On Linux or Unix, an equivalent one-line form is:

rman TARGET '"/ AS SYSBACKUP"' NOCATALOG

Shell quoting varies by platform, which is why the two-step procedure is the primary example. In either form, NOCATALOG selects the target control file as the exclusive repository for the session.

Password-file authentication supports local or remote access. The password file must include the target account with the required administrative privilege. The Oracle Net service must resolve from the host where the RMAN client runs.

Start the client without a catalog, then connect through the root service:

rman NOCATALOG

RMAN> CONNECT TARGET "backup_admin@prodcdb AS SYSBACKUP";

RMAN requests the password interactively. Do not place it after the user name. A plain-text password on the operating-system command line can be captured in shell history, process information, scheduler definitions, monitoring output, screenshots, or diagnostic collections.

The quotation marks are required because the connection string includes AS SYSBACKUP. If the privilege text is omitted, RMAN assumes AS SYSDBA. A successful authentication therefore does not prove that the task-specific privilege was used unless the connection string or approved account design makes that fact explicit.

The service prodcdb must reach the target CDB root. TNSPING prodcdb can test connect-identifier resolution and listener reachability, but it cannot prove database availability, authentication, container scope, or target identity. The authenticated RMAN connection is the meaningful end-to-end test.

Do not treat the appearance of the RMAN> prompt as sufficient evidence. Read the connection messages and compare the database name and DBID with the approved target record. A successful control-file-only connection reports the target and indicates that RMAN is using the target control file instead of a recovery catalog.

connected to target database: PRODCDB (DBID=1234567890)
using target database control file instead of recovery catalog

The DBID above is illustrative. Do not copy it into a runbook. The real DBID is a durable database identity and is especially important when database names, restored environments, standby databases, or duplicated databases can look similar.

Use read-only RMAN commands to examine the connected scope before changing configuration or repository records:

REPORT SCHEMA;
SHOW ALL;
LIST BACKUP SUMMARY;

REPORT SCHEMA shows the data-file and tablespace structure visible to the target connection. SHOW ALL displays persistent RMAN configuration for the target. LIST BACKUP SUMMARY reports backup records known to the control-file repository.

These commands verify identity and inventory, not recoverability. A listed backup can be missing, inaccessible, damaged, or insufficient for the required recovery objective. CROSSCHECK, VALIDATE, restore validation, and recovery rehearsals answer different questions. Use each according to an approved procedure rather than treating one successful report as proof that the database can be recovered.

Oracle 26ai RMAN can operate on an entire CDB, the root, one PDB, or multiple PDBs. The target connection determines which commands and objects are available.

RMAN target scope in a multitenant database

Intended work	Connection	Important boundary
Whole CDB	Connect to the CDB root	Use an appropriately privileged common user
Root only	Connect to the CDB root	The command must select root scope
One PDB from the root	Connect to the CDB root	Use RMAN PLUGGABLE DATABASE syntax
One PDB directly	Connect to a service for that PDB	Several database-level RMAN operations are unavailable
Multiple PDBs	Connect to the CDB root	Select the PDBs in the RMAN command

A local operating-system authenticated RMAN connection to a CDB reaches the root. Direct PDB connections use an Oracle Net service for the PDB and have restrictions affecting archived redo log management, configuration, obsolete reporting, registration, incarnation, duplication, and selected recovery operations. This lesson uses the root because it establishes a database-level control-file repository session.

In a NOCATALOG session, the target control file is the only repository visible to RMAN. Protecting that file and retaining sufficient record history are therefore core requirements. Enable control-file autobackups unless a reviewed architecture supplies an equivalent, documented protection method:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

A control-file autobackup can also include the server parameter file when the database uses an SPFILE. This capability supports recovery when the current control file is lost, but it does not replace data-file, archived redo log, or broader recovery protection.

The initialization parameter CONTROL_FILE_RECORD_KEEP_TIME controls the minimum age before reusable control-file records can be overwritten. It must align with the backup cycle, retention policy, reporting requirements, and the oldest metadata that must remain available for recovery or later catalog resynchronization.

Do not set the parameter to zero as a general tuning shortcut. A zero value permits reusable records to be overwritten without regard to age. Do not copy one numeric setting to every database either. Record volume, control-file capacity, retention requirements, and workload determine the correct value. A recovery catalog can preserve older synchronized history, but it does not eliminate the need to protect the target control file.

Most core RMAN operations do not require a recovery catalog. The important distinction is metadata history and catalog services, not whether RMAN can create a usable physical backup.

Capabilities with and without a recovery catalog

Capability	Available in NOCATALOG mode?	Qualification
Backup sets, image copies, and incrementals	Yes	Metadata is stored in the target control file
Restore, recovery, and validation	Yes	Required records and backup data must remain available
LIST, REPORT, and SHOW	Yes	Results are limited to control-file repository records
CROSSCHECK, DELETE, and CHANGE	Yes	Normal scope, authorization, and safety controls still apply
Catalog stored scripts	No	Stored scripts reside in the recovery catalog
Centralized reporting across registered targets	No	The session has no shared catalog repository
Virtual private catalogs	No	They depend on a base recovery catalog
History beyond retained control-file records	No	A catalog can retain synchronized records for a longer period

Do not describe incremental backups, image copies, corruption checking, tablespace point-in-time recovery, or validation as catalog-only features. Their detailed prerequisites differ, but a recovery catalog is not what makes those basic RMAN capabilities possible.

Oracle requires a recovery catalog when RMAN is used in a Data Guard environment. Do not design a primary and its physical standbys around isolated NOCATALOG repositories. The catalog supplies the metadata authority across the databases in that Data Guard environment.

A catalog outage does not remove the repository records in the target control file. An authorized operator can start a new NOCATALOG session for an approved target operation when the runbook permits it. This is a continuity option, not permission to bypass policy, Data Guard requirements, stored-script dependencies, or destructive-command safeguards.

Before proceeding, confirm that the required metadata still exists in the control file, that the operation does not depend on older catalog history or a catalog stored script, and that concurrent automation will not be confused by the mode change. Record the outage, the target DBID, the commands executed, and any later catalog resynchronization that the procedure requires.

If the wrong repository mode was selected and a repository-dependent command has already run, exit the client:

EXIT;

Then start a new RMAN client with the intended mode. Reconnecting the target does not convert an active control-file-only repository session into a catalog-aware session.

Read the complete Oracle and RMAN error stacks before changing configuration. A connection problem can originate in the local environment, Oracle Net naming, listener registration, password-file authorization, or container scope.

Initial RMAN connection checks

Symptom	Boundary	First checks
Wrong local database	Oracle environment	ORACLE_SID, Oracle home, executable path, and instance identity
Connect identifier is unresolved	Oracle Net naming	Service spelling, naming method, and active client configuration
Listener cannot supply the service	Network or registration	Listener address, service state, PDB state, and LREG registration
Administrative authentication fails	Privilege or password file	SYSBACKUP grant, OS group, password file, and container
Connection reaches the wrong scope	Service definition	Database name, DBID, root or PDB service, and approved target record
Catalog connection is rejected after repository use	RMAN session mode	Exit and start a new catalog-aware session

For local authentication, an approved SQL client can reproduce the administrative connection with / AS SYSBACKUP. For a remote problem, test the same service, account, and privilege that RMAN uses. An ordinary application login does not verify password-file authentication or RMAN's administrative connection path.

1. Select the intended target instance, Oracle home, and RMAN executable.
2. Choose local operating-system authentication or a named password-file identity.
3. Start RMAN with explicit NOCATALOG mode.
4. Connect to the CDB root with the approved SYSBACKUP or SYSDBA authority.
5. Keep passwords out of commands, files, logs, screenshots, and scheduler definitions.
6. Compare the connected database name and DBID with the approved target record.
7. Confirm the message stating that RMAN is using the target control file instead of a recovery catalog.
8. Review the schema, persistent RMAN configuration, and known backup inventory before making changes.
9. Verify control-file autobackup and repository-record retention against the recovery design.
10. Exit and restart RMAN if a recovery catalog is required after repository use begins.

The session is now ready for approved control-file-only RMAN work. No recovery catalog has been maintained in this lesson because no catalog connection exists. Later lessons apply registration, incarnation, resynchronization, change, deletion, and validation commands to their appropriate repository scopes.

Test your understanding of recovery-catalog and NOCATALOG connection choices.
Recovery Manager Catalog Quiz