Database Recovery with the RMAN Command Line in Oracle 26ai

Recovery Manager, or RMAN, is the command-line client for Oracle AI Database 26ai backup and recovery. You can use it interactively during an incident or run a reviewed command file. The essential sequence is to identify the failure, establish a recovery goal, locate usable backups and redo, restore files when necessary, apply recovery, and verify the database before returning it to service.

RESTORE and RECOVER perform different jobs. Restore copies files from backups or image copies to their required destinations. Recovery applies incremental backups and redo changes to bring those files to a consistent target. A restored datafile may still be older than the other database files. Opening immediately after restore can therefore fail or leave the intended recovery incomplete.

The examples below illustrate separate recovery scenarios. They assume an authorized administrator, suitable backups and access to the required storage. They do not represent commands already executed or a universal procedure for every failure. Whole-database operations in this lesson target a single-instance CDB from its root; recovery of one PDB, RAC coordination and Data Guard role transitions require their respective procedures.

Record the reported errors, affected file numbers, database state and recent operational changes. Check the alert log and storage availability. A temporary access problem, a missing datafile and a lost control file call for different actions. Preserve the original error information and recovery logs so that later decisions can be explained and reviewed.

An instance crash does not automatically require restoring backups. Oracle normally performs instance recovery during startup when the necessary files and redo remain available. Media recovery addresses files that must be brought forward using redo, often after damage, loss or restoration of an older copy. Replacing an intact file merely because the instance stopped can add unnecessary work and introduce another recovery requirement.

Determine whether the goal is complete recovery, preserving all committed changes that can be recovered, or an intentional return to an earlier point. Identify whether the current control file remains usable. These decisions determine backup selection, the scope of restore and whether the final open requires RESETLOGS. Consult the 26ai complete recovery guide for the applicable prerequisites.

ORA-01113 reports that a file needs media recovery when an operation attempts to open or bring it online. It is a diagnostic condition, not an instruction to restore the entire database. Identify the file named by the accompanying messages and determine whether it is accessible and needs only recovery, or whether a usable copy must first be restored.

When the database is mounted and the appropriate views are available, an administrator can inspect file headers in a separate SQL session:

SELECT file#, status, error, recover, tablespace_name, name
FROM v$datafile_header
WHERE recover = 'YES'
   OR (recover IS NULL AND error IS NOT NULL);

Header information is useful but does not inspect every data block for corruption. V$RECOVER_FILE can also help with a current control file, but Oracle cautions that its information is not reliable after restoring a backup control file or re-creating one after the relevant failure. Combine view results with the error stack and recovery evidence.

The legacy suggestion to run REPAIR CATALOG is invalid. There is no RMAN catalog-repair command with that syntax that resolves ORA-01113. A recovery catalog stores RMAN metadata; repairing or refreshing metadata does not apply redo to a datafile. Oracle's ORA-01113 description identifies media recovery as the required action.

With the target mounted for the planned whole-database restore, review the repository and channel configuration before copying files:

REPORT SCHEMA;
SHOW ALL;
LIST BACKUP OF DATABASE;
RESTORE DATABASE PREVIEW;
RESTORE DATABASE VALIDATE;

REPORT SCHEMA helps identify the recorded files. SHOW ALL displays persistent RMAN configuration, including automatic channels. LIST BACKUP reports repository records. Preview shows which backups RMAN would select; it does not prove that every backup block can be read. Restore validation reads selected backup contents without writing restored database files. Schedule that I/O appropriately.

These checks improve confidence but do not constitute a successful recovery test. The required redo, encryption keys, destinations and application recovery target must also be verified. For backups created with transparent encryption, make the required keystore available. Password-encrypted backups require their corresponding decryption credentials through the supported procedure.

RMAN normally selects suitable backups automatically. The old RESTORE DATABASE FROM BACKUPSET 'backupset1' example is invalid. A tag can constrain selection with supported syntax such as RESTORE DATABASE FROM TAG 'FULL_CDB', but a tag is not a backup-set filename, and the selected backups still must support the intended recovery target.

Disk channels access storage from the database server. SBT channels require a configured media-management integration and access to its backups. Typing a tape channel allocation does not install or configure that integration. Verify the provider library, settings and restore access before depending on tape or object-storage backups during an outage.

Database point-in-time recovery deliberately omits changes after an agreed target. Use it when the incident requires an earlier consistent state and suitable flashback options are unavailable or inappropriate. Establish the target with application owners and retain the evidence used to choose it. A whole-CDB recovery affects its PDBs, so it must not be confused with recovering one application PDB independently.

With the CDB mounted, set the recovery target before both restore and recovery in the same RUN block. The date below is an illustrative target, not a recommendation for the current database:

RUN {
  SET UNTIL TIME
    "TO_DATE('2026-10-04 06:00:00','YYYY-MM-DD HH24:MI:SS')";
  RESTORE DATABASE;
  RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;

The explicit format removes dependence on a session's default date format. Verify how the chosen database time maps to the incident timeline; do not silently assume it matches a workstation's time zone. SCN or redo-sequence targets are alternatives when appropriate, with their documented boundary and thread semantics.

Applying SET UNTIL before restore ensures that RMAN selects files old enough for the intended target. Restoring a recent backup and then attempting to recover backward is not the normal media-recovery method. The legacy RECOVER DATABASE TO TIMESTAMP example should not be used as RMAN syntax.

After successful incomplete recovery, RESETLOGS establishes a new incarnation. Later changes are outside the recovered state. Do not issue RESETLOGS to suppress a missing-redo error without explicitly changing and approving the recovery goal. Oracle's 26ai point-in-time recovery guide covers the prerequisites and separate CDB/PDB procedures.

First check whether an intact current multiplexed copy survives. Recovering access through that copy differs from restoring an older backup. If every current copy is lost, an available control-file autobackup can provide the metadata needed to mount the database and continue recovery.

The following example assumes a usable SPFILE or other suitable initialization file, the correct local instance, no recovery catalog connection, and an accessible disk autobackup that RMAN can locate with the applicable search settings. Replace the sample DBID with the database's previously recorded real value:

STARTUP NOMOUNT;
SET DBID 123456789;  # Illustrative DBID: replace before use.
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

This sequence addresses the control file and assumes the datafiles remain usable. If datafiles are also lost or must be replaced, restore the necessary files after mounting and before recovery. The recovery target and available redo still determine the achievable result. A control-file restore does not itself restore datafiles or guarantee that all changes can be recovered.

In this no-catalog situation, the DBID identifies the intended database for autobackup discovery. Nondefault autobackup naming or locations can require SET CONTROLFILE AUTOBACKUP FORMAT and suitable search options. Configure them from the actual backup records. Do not assume that every backup resides in the fast recovery area or uses the same disk naming convention.

If the SPFILE is also unavailable, follow the documented SPFILE restoration procedure first. Tape or other SBT autobackups require usable provider channels. Recovery with a restored backup control file requires media recovery and then RESETLOGS, even when no datafiles had to be restored. Keep this requirement separate from the normal-open example that uses the current control file.

RMAN is a current Oracle 26ai utility, not an Oracle9i-only interface. It coordinates database-server processes through channels, whether you type commands interactively or supply a command file. Check syntax against the 26ai RESTORE reference and the corresponding RECOVER documentation.

A snapshot control file gives RMAN a consistent metadata view for operations such as catalog resynchronization. It is not the retained control-file backup used for disaster recovery. Inspect its configured location rather than assuming the old Windows path shown in legacy lessons:

SHOW SNAPSHOT CONTROLFILE NAME;

Successful recovery combines a suitable procedure with usable recovery resources and verified results. Carry that distinction into the next lesson, which explains RMAN tablespace recovery and related control-file and archived-log operations.