Oracle 26ai Database Recovery with RMAN and Enterprise Manager

What changes from the legacy Recovery Wizard?

The old desktop wizard illustrated useful choices, but its screens and default credentials should not be copied into a current procedure. Use your organization's assigned Enterprise Manager account and configured database and host credentials. Cloud Control, its database plug-in, and the database have separate versions: confirm support for the actual combination installed at your site. Menu wording and available operations can vary.

One particularly important change concerns automatic failure advice. Data Recovery Advisor is desupported in Oracle AI Database 26ai, including LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE. Do not base a new runbook on that older guided repair feature. User-directed RMAN recovery remains a distinct process. See Oracle's 26ai desupport notice.

Choose the recovery scope and endpoint first

Start with the incident evidence: the database alert log, operating-system or storage errors, affected application, container identity, and failed file numbers. A connection failure alone does not prove that a datafile needs restoring. An unavailable listener, full filesystem, or interrupted instance can require a different response. Avoid overwriting healthy files before establishing what failed.

SYSTEM and active undo require separate procedures; the ordinary application-tablespace example below does not apply to them. Likewise, an open database does not mean every recovery operation is available without an outage. Select the smallest appropriate scope while accounting for dependencies and the supported procedure for that scope.

Complete recovery brings the selected files forward through the available required redo to the current consistent endpoint. Point-in-time recovery intentionally returns a database or supported recovery scope to an earlier state. The latter can discard later changes and needs an explicitly chosen endpoint and a different runbook. A restore by itself does not accomplish either business outcome.

Check recovery readiness

Write down the target database, DBID where relevant, CDB/PDB, affected files, intended endpoint, and expected application interruption. These details make the proposed operation reviewable and help another administrator recognize a connection to the wrong environment. Establish where the recovery log and incident notes will be kept before starting an operation that may take hours.

• For the online-backup recovery examples, confirm ARCHIVELOG mode, suitable backups, and the redo needed after those backups.
• Confirm that the database server can access the backup media and destination storage, with sufficient capacity and correct permissions.
• Check configured disk or SBT channels. A backup stored through a media manager needs the corresponding working restore configuration.
• Make the required encryption keys or backup decryption credentials available through the approved operational procedure.
• Establish whether the current control file is intact. Restoring a backup control file changes the recovery and opening procedure.

Use repository information to plan the restore, and use validation when you need to read the backup contents. For example, in the intended target context:

SHOW ALL;
RESTORE DATABASE PREVIEW;
RESTORE DATABASE VALIDATE;

PREVIEW reports the backups selected from metadata. VALIDATE reads the selected backups without restoring datafiles. Neither command is a substitute for a rehearsed end-to-end recovery. Validation also consumes storage and media bandwidth, so include its cost in the incident plan. Oracle's RESTORE reference describes selection, access, and encryption requirements.

Use Enterprise Manager for user-directed recovery

Oracle's 26ai guide documents a Cloud Control tablespace recovery flow beginning on the database home page. Open Availability > Backup & Recovery > Perform Recovery, select the tablespace scope under user-directed recovery, and choose recovery to the current time when complete recovery is intended. Select the affected tablespace and its PDB where applicable, then follow the recovery pages. See Performing Complete Database Recovery.

At each page, translate the selection into a concrete recovery decision. Is the target a whole database or one application tablespace? Will files be restored or only recovered? Are original paths usable? Which credentials and channels will run the job? Is the endpoint current time or a deliberately selected historical state? Do not accept a remembered default merely because it worked on another database.

Before submitting, inspect the operation summary and generated commands when the interface exposes them. Record the selected objects, destination paths, recovery endpoint, and job identity. After submission, read the job's RMAN output. A submitted job is not a completed recovery, and a successful restore phase does not establish that the later recovery phase succeeded. Keep the CLI procedure accessible outside the management system so that a management outage does not remove your recovery instructions.

Complete tablespace and datafile recovery at a glance

The diagram consolidates the earlier selection and rename screens into one operational sequence. It is a teaching illustration, not a screenshot of Cloud Control. Its open-PDB example should not be mistaken for the whole-CDB procedure below. The distinction matters because an otherwise correct command can have the wrong scope when executed through the wrong connection.

Example: complete recovery of a whole CDB

Assume that datafiles have been damaged, the current control file and server configuration remain usable, suitable backups and required redo are accessible, and the intended endpoint is complete recovery. Connect RMAN to the CDB root with an appropriately privileged account. A root connection uses a common user with SYSBACKUP or SYSDBA; follow the documented authentication procedure and avoid embedding passwords in scripts. See Starting and Interacting with the RMAN Client.

If the instance is stopped, start it mounted. If it is already open, perform the planned shutdown and mount transition first; do not issue startup blindly. With the target mounted, the illustrative RMAN sequence is:

STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;

Read the recovery output and resolve any errors before opening. When complete recovery using the current control file has succeeded, the normal opening command is:

ALTER DATABASE OPEN;

Verify the required PDB states and services as well as the root database state. Opening the CDB alone does not prove that each application can reconnect. If the control file was lost, restore it through the appropriate separate procedure before attempting this sequence. Recovery with a backup control file requires recovery followed by OPEN RESETLOGS; database point-in-time recovery also requires RESETLOGS. That operation is not a shortcut around unresolved recovery errors. Oracle's advanced recovery scenarios cover those cases.

Example: an application tablespace in an open PDB

Suppose an existing permanent USERS tablespace has damaged datafiles while other application storage remains usable. Connect RMAN directly to the intended PDB for this named-tablespace example, using a local or common account authorized as SYSDBA according to the documented direct-PDB connection procedure. Verify the service and container before using the tablespace name: different PDBs can contain a tablespace called USERS.

After checking the backup chain and arranging the application interruption, use the following illustrative RMAN commands. The SQL command passes the quoted statement to the target database:

SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;

Inspect the output before continuing. After successful recovery, return the tablespace online:

SQL 'ALTER TABLESPACE users ONLINE';

This deliberate pause keeps the verification decision visible. Test access to representative application objects after bringing storage online, and confirm that the application has recovered from any failed transactions or disconnected sessions. The example does not restore a dropped tablespace, handle missing SYSTEM files, or recover active undo. An accidentally dropped object may need a separately planned historical recovery or extraction workflow.

When recovery without restore is appropriate

A restore replaces a missing or unusable file with a backup. Recovery applies changes needed to advance a suitable file. If the correct datafile is still present and only needs redo applied, a recover-only operation can be appropriate after diagnosis and the required state transition. Do not restore an older copy simply because a wizard offers a restore option.

Conversely, an existing pathname does not establish that a file is healthy or belongs to the intended database. Check the diagnostic evidence and file identity. Missing redo cannot be repaired by repeatedly running the same restore. Reassess the available recovery paths and their endpoints instead of improvising an incomplete recovery during an outage.

Restore to another location when necessary

If the original storage cannot be reused, decide the replacement path before restoring. The following alternative assumes that datafile 7 belongs to the affected, already offline application tablespace and that the destination directory exists on the database server. Replace both the file number and path with verified values:

RUN {
  SET NEWNAME FOR DATAFILE 7 TO '/u02/oradata/app/users01.dbf';
  RESTORE DATAFILE 7;
  SWITCH DATAFILE ALL;
  RECOVER DATAFILE 7;
}

Within this run block, SET NEWNAME selects the destination and RESTORE writes the file. SWITCH DATAFILE ALL switches the files assigned new names in the block; here that is datafile 7. It updates control-file references rather than moving operating-system files. Recovery then uses the current file reference. Review the SET reference and SWITCH reference when adapting this pattern.

Do not run this alternative after a successful original-location restore merely to imitate every box in the diagram. Select one placement strategy. Before returning the affected tablespace online, verify that all of its required files are recovered and that their recorded locations match the intended storage. Update the operational inventory so later administrators can find the restored files.

Temporary files and Recovery Appliance considerations

The legacy simulation selected TEMP as if it were a permanent tablespace. RMAN does not back up, restore, or recover tempfiles. They are recreated when required, with their paths, capacity, and configuration checked separately. Do not substitute TEMP into the permanent USERS example.

If backups reside in a Zero Data Loss Recovery Appliance, keep the same distinction between restoring files and applying redo, but use the site's configured Recovery Appliance restore procedure. The recovery catalog supplies metadata; it is not itself the physical backup storage. Required catalog access, SBT library and channel settings, network connectivity, and credentials must already be established. A generic disk example does not configure an appliance connection.

Work through a recovery decision

Consider an application that reports read errors after a storage failure. The CDB and affected PDB are open, but one permanent application datafile is unavailable. Begin by mapping the reported file number to the correct container and tablespace. Confirm the physical failure and check whether other files on the same storage are affected. This prevents a narrow recovery plan from overlooking a broader storage problem.

Next, establish whether the original destination is reliable. If it is, plan an original-location restore and recovery. If it is not, choose and verify replacement storage, then include the relocation commands in the reviewed plan. In either case, check that the selected backups and required redo can be read. Record which application functions will remain unavailable while the affected files are offline.

Now compare a different incident: a user deleted business rows, but every datafile remains physically healthy. Restoring the current backup and applying all subsequent redo would also replay that deletion. The recovery objective is therefore different. Establish the desired historical state and evaluate an appropriate logical, Flashback, or point-in-time recovery method before changing files. The media-recovery workflow in this lesson should not be applied automatically to every form of data loss.

Verify recovery before closing the incident

Use both technical and application evidence. Preserve the RMAN or Enterprise Manager job output and check the complete error stack if any phase failed. Confirm the intended files, tablespace states, container states, and actual file locations. Review the alert log for new storage or recovery errors, then run representative application checks with the application owner.

Record the recovery endpoint, any relocated files, the backup and redo sources used, and follow-up work needed to restore normal protection. Arrange subsequent backups according to the resulting database state and your recovery policy. A green job indicator is useful evidence, but service readiness also requires working application connections and the expected data. The next lesson concludes this module.