Use Recovery Manager Interactively in Oracle AI Database 26ai

Oracle Recovery Manager (RMAN) is the database client used to manage physical backups, restore database files, and perform recovery. In this lesson, you will start the client, connect to a target database, inspect its configuration and backup records, and understand the operations available at the interactive prompt. These skills apply whether an administrator runs RMAN directly or uses Enterprise Manager to schedule backup jobs.

Starting RMAN and starting a database instance are separate actions. The operating-system command rman launches the client. A target connection identifies the database on which subsequent commands operate. Database startup, shutdown, backup, and recovery happen only when the corresponding operations are requested. The inspection examples below assume an authorized target that is already mounted or open.

Prepare the connection environment

The RMAN executable is installed with Oracle Database software, usually in the Oracle home bin directory. Use the executable from the installation appropriate to the target database. If that directory is in your operating-system search path, you can enter rman directly. Otherwise, launch it using its actual full path. Linux and Windows use different environment-setting and path conventions, but the commands entered inside RMAN follow the same command language.

Before connecting locally, confirm the Oracle installation environment and set ORACLE_SID to the intended instance. On a server with several instances or Oracle homes, a successful connection to the wrong database is still the wrong connection. Check the target identity reported by RMAN before proceeding. In a multitenant database, local operating-system authentication connects to the container database (CDB) root.

Target and auxiliary connections require the SYSBACKUP or SYSDBA administrative privilege. For local operating-system authentication, the operating-system account must belong to the appropriate OSBACKUPDBA or OSDBA group. For a remote connection, a named account needs the required administrative privilege and password-file authentication, and Oracle Net must resolve the service to the intended database or container.

A dedicated backup administrator should use an explicitly granted SYSBACKUP privilege when it meets the task's requirements. This separates backup responsibilities from the broader authority of SYSDBA. The account and service names in this lesson are examples; substitute the names configured for your environment. Enter passwords when prompted rather than embedding them in commands or saved scripts.

Start RMAN and connect interactively

At the operating-system command prompt, start the client without a connection string:

rman

RMAN displays its own RMAN> prompt. At this point, the client is running, but you have not selected a target. Connect using a named backup account and an Oracle Net service:

RMAN> CONNECT TARGET "sbu@prod AS SYSBACKUP";

Here, sbu represents an account granted SYSBACKUP, and prod represents the configured Oracle Net service. RMAN requests the password separately. The enclosing quotation marks are needed because the connection string includes an explicit administrative privilege. For operations on an entire CDB, the service must connect to the root and the account must be an appropriately privileged common user.

For a local connection using operating-system authentication, an OSDBA member can launch the client and connect in one command:

rman target /

The slash connection shown here implicitly uses SYSDBA. It does not automatically select SYSBACKUP. To request the backup privilege explicitly, start rman without a target and then enter:

RMAN> CONNECT TARGET "/ AS SYSBACKUP";

This local form requires OSBACKUPDBA membership and the correct ORACLE_SID. Both approaches establish a target connection; neither issues a database STARTUP command. RMAN can also connect to an instance that is not open for recovery work, but the instance state required by each subsequent operation still matters.

Understand target and repository scope

The target is the database whose files RMAN protects. A recovery catalog is an optional schema in a separate database that stores additional RMAN metadata. An auxiliary connection supports operations such as database duplication or certain point-in-time recovery workflows. These are distinct roles, and a routine inspection session normally needs only the target connection.

Without a recovery catalog, RMAN uses the target database control file as its repository. The repository describes backups, copies, and other recovery information; it is not the location of the backup pieces themselves. A recovery catalog can provide longer metadata history and records for multiple targets. Enterprise Manager's management repository serves a different purpose and does not replace the RMAN repository.

If your environment uses a recovery catalog, connect it before running commands that establish repository use in NOCATALOG mode. Once a repository-dependent command has selected that mode, exit and restart RMAN to add a catalog connection. The next lesson covers catalog creation, so this lesson's initial walkthrough uses the target control file.

Connection scope is especially important in a CDB. Connect to the root for whole-CDB operations or a command covering multiple PDBs. From the root, commands can explicitly identify selected pluggable databases. A direct target connection to one PDB supports operations for that PDB, with restrictions that do not apply to a root connection. A service name alone does not establish scope; verify which container the service actually reaches.

Inspect the target without changing its configuration

After connecting, enter each command at the interactive prompt and review its output before continuing:

RMAN> SHOW ALL;
RMAN> REPORT SCHEMA;
RMAN> LIST BACKUP SUMMARY;

These commands provide a useful first tour. They do not create backups, delete files, or change persistent backup configuration. They report the connected target and the repository available to the session. Output varies with the database structure, configuration, and recorded backup history; the examples show commands rather than invented results.

Use LIST BACKUP; when you need more detail than the summary provides. Repository records help identify what RMAN knows about, but a record alone does not prove that a backup file is accessible or that recovery will succeed. Crosschecks and validation serve additional purposes and are not implied by running LIST.

In the examples, RMAN> marks the client prompt and is not part of the command you type. Most RMAN commands end with a semicolon. If a command is incomplete, RMAN displays numbered continuation prompts and waits for the rest. Those prompt numbers also belong to the display, not to a command file.

A consolidated view of the interactive workflow

The diagram groups the main capabilities into one view. Connection establishes the target and administrative privilege. Inspection shows configuration, database structure, and backup records. Configuration controls how later jobs operate. Repository choices determine where their metadata is maintained. The backup, recovery, and automation features build on those foundations.

Explore persistent settings and channels

The SHOW command reads existing settings. The CONFIGURE command changes persistent defaults for the target. Examples of configurable choices include the backup device type, channel options, backup format, parallelism, retention policy, and control file autobackups. Examine the current settings and the site's recovery requirements before changing them; configuration persists beyond the current client session.

An RMAN channel represents a data stream associated with a database server session. Channels perform backup and restore I/O. A disk channel writes to storage accessible to the server session, while an SBT channel uses a supported media-management integration. The terminal where the RMAN client runs is not necessarily the server or the backup storage location.

More channels do not automatically mean a better backup. Available storage throughput, server resources, media-manager capabilities, and recovery goals determine a suitable configuration. Likewise, a client output log is separate from the backup destination. Logging the session records what RMAN reports; it does not redirect backup pieces.

Retention settings describe which backups are needed for the configured recovery policy. They do not make every old file disappear when a session starts. Backup maintenance commands have their own effects. Keep configuration inspection separate from changing settings or removing backups so that each action has an understood purpose.

Distinguish backup, restore, and recovery

Backup creates recoverable copies of protected content. Restore retrieves database files from backups. Recover applies the required changes, including redo, to bring files to the chosen recovery point. Restoring a file is therefore not necessarily the last step in returning a database to service.

RMAN can protect a CDB, selected PDBs, tablespaces, data files, archived redo logs, the control file, and the server parameter file (SPFILE), subject to connection scope and command prerequisites. These objects have different roles. Data files contain database data, archived redo supports recovery, the control file records database structure and RMAN metadata, and the SPFILE stores instance configuration.

For an authorized test environment, the following illustrates a database backup that also includes archived redo:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

This example assumes a CDB-root connection, an appropriate mounted or open target in ARCHIVELOG mode, configured backup destinations, sufficient storage, and access to the required files. Unlike the earlier inspection commands, it performs work and creates backups. The PLUS ARCHIVELOG clause includes archived redo associated with the backup workflow; it is not a substitute for a complete recovery plan.

After a backup, inspect its records and job output. Testing restore and recovery answers questions that a successful backup completion alone cannot answer, including whether files are available and whether the intended recovery point can be reached. A restore or recovery procedure must match the failure, file state, available backups, and redo. Do not use a generic RESTORE DATABASE sequence as an introductory inspection step.

Read backup terminology accurately

Backup format, incremental level, database state, and consistency describe different properties. One backup can belong to several of these categories. For example, an online level 1 backup can be stored as a backup set and require recovery using redo. Treating the terms as mutually exclusive backup types makes planning harder.

An online data-file backup requires ARCHIVELOG mode so that the needed changes can be available for recovery. A consistent closed backup follows a clean shutdown and is taken while the database is mounted but not open. Merely closing the database does not establish consistency if it crashed or was shut down with ABORT. Database state and backup consistency must be considered together.

Record sessions and reuse commands

For an interactive session whose output should be retained, start the client with a log destination:

rman target / log /path/to/rman-session.log append

Replace the example path with a real writable path on the client host. The local target connection has the same OSDBA and environment requirements as before. APPEND adds output to an existing log instead of replacing its contents. Logs are useful for reviewing commands, errors, and completion messages, but they are not backup files or an independent recovery catalog.

Once a command sequence is understood, save it in a command file for repeatable use. A simple inspection file might contain these lines without interactive prompt prefixes:

SHOW ALL;
REPORT SCHEMA;
LIST BACKUP SUMMARY;

If that file is saved as inspect.rman in the client's current directory, a connected session can run it using:

RMAN> @inspect.rman

RMAN processes the file and returns to the interactive session. Command files are filesystem text files; catalog stored scripts are a separate feature requiring a recovery catalog. Scheduling either kind of work also requires the surrounding job environment to supply the correct target, authentication, and resources.

Use Enterprise Manager alongside the client

Enterprise Manager offers an optional management interface for configuring, scheduling, and monitoring RMAN work on managed targets. A backup workflow generally identifies the target, scope, destination, credentials, and schedule, then provides job status and output. The available screens depend on the Enterprise Manager release, database plug-in, and target configuration.

The RMAN client remains useful for inspecting a target, investigating a failed job, and performing supported recovery when the management interface is unavailable. Understand the underlying RMAN operation rather than relying on the position of an old wizard button. An Enterprise Manager job record and an RMAN backup record also answer different questions: one describes job execution, while the other describes recovery-related metadata.

Finish the interactive session

To end the client session, enter:

RMAN> EXIT;

QUIT also exits RMAN. Exiting disconnects the client; it does not shut down the target database. RMAN has explicit STARTUP and SHUTDOWN commands for procedures that require changing instance state, but those commands are separate from launching or closing the client.

You should now be able to choose a target connection, identify its scope and privilege, inspect configuration and backup records, and distinguish inspection from backup or recovery work. The next lesson explains how to create a recovery catalog and use it to maintain RMAN metadata.

Oracle 26ai references

• Starting and Interacting with the RMAN Client
• Getting Started with RMAN
• Configuring the RMAN Environment
• RMAN Backup Concepts