Lesson 1

Oracle 26ai Complete Recovery in ARCHIVELOG Mode

Oracle AI Database 26ai supports complete media recovery for a database operating in ARCHIVELOG mode. After damaged or missing datafiles are restored from backup, Recovery Manager, or RMAN, applies the required incremental backups, archived redo logs, and available online redo. The objective is to advance the restored files to the latest consistent state supported by the complete recovery chain.

Complete recovery differs fundamentally from restoring a NOARCHIVELOG database. A NOARCHIVELOG restore is normally limited to the latest usable consistent backup and any applicable consistent incremental backups. In ARCHIVELOG mode, preserved redo can carry an older restored datafile forward through changes made after the backup.

Complete recovery is also different from point-in-time recovery. Complete recovery applies all required available redo and does not intentionally stop at an earlier SCN or time. When the current control file is used and recovery completes successfully, the database normally opens without RESETLOGS.

Complete Recovery and Point-in-Time Recovery

The DBA must identify the intended recovery operation before running restore commands. The same backup can participate in different recovery plans, but the recovery endpoint and final open command are not interchangeable.

Complete recovery compared with incomplete recovery
Complete recovery	Incomplete or point-in-time recovery
Applies all required redo available through the latest recoverable consistent SCN.	Stops at a selected SCN, time, restore point, or log sequence.
Attempts to preserve all committed work represented by the available recovery chain.	Intentionally abandons database changes after the selected recovery target.
Normally opens with `ALTER DATABASE OPEN` when the current control file is used.	Opens with `ALTER DATABASE OPEN RESETLOGS`.
Does not use an RMAN `SET UNTIL` recovery limit.	Establishes a recovery limit before restoration and recovery.

A restored backup is not automatically current. The backup supplies an earlier copy of each damaged file. Complete recovery must then locate and apply an unbroken sequence of required changes. If a required archived log is missing and the same redo is unavailable from another valid source, complete recovery cannot reach the current database state.

Instance Recovery Is Not Media Recovery

A database instance can fail even when its storage remains intact. Following an unexpected termination, Oracle normally performs instance recovery during startup. It uses the current datafiles, control files, online redo, and undo. An administrator does not normally restore a datafile backup merely because an instance crashed.

Media failure means a required file has become unavailable or unusable. Examples include a failed file system, lost ASM disk group, damaged datafile, or missing control-file member. Restarting the instance cannot reconstruct a missing datafile from memory. The DBA must diagnose the damaged structures and decide whether to repair access, restore selected files, restore a PDB, or restore the entire CDB.

The distinction matters because restoration replaces file contents. A permissions problem or dismounted storage device can resemble file loss. Repairing access to an intact current file is usually faster and safer than restoring an older backup over it.

How ARCHIVELOG Mode Preserves the Recovery Chain

LGWR writes redo concurrently to all valid members of the current online redo log group. When a log switch occurs, LGWR begins writing to another group. In ARCHIVELOG mode, a filled group cannot be reused until the required archiving has completed. This protects the redo history needed for media recovery.

An archived redo log is an offline copy of a filled member of an online redo log group. Archiver processes, identified as ARCn, normally create these copies when automatic archiving is enabled. Multiple archive destinations can provide redundancy, and RMAN can back up archived logs to disk, object storage, tape, or another configured backup destination.

Multiplexed online redo members and archived redo solve different problems. Multiplexing protects a current group against loss of one member. Archiving retains completed redo sequences after the online group is reused. RMAN does not back up online redo logs, so they must not be treated as ordinary datafile backup contents.

Surviving online redo can contain the newest changes required to complete recovery after all archived sequences have been applied. Complete recovery may therefore use both archived and online redo. The DBA should protect online groups with appropriately separated members and protect archived redo with a retention strategy that matches the recoverability requirement.

Restore and Recover Are Separate Operations

Restore retrieves a file from an RMAN backup set or image copy. Recover applies the changes required to bring that restored file to a consistent recovery endpoint. RMAN can use incremental backups to reduce the amount of redo that must be applied, but incrementals do not eliminate the need for all recovery inputs needed after their checkpoint.

A backup can be physically readable and still be insufficient for complete recovery. The operation also needs a usable control file or recovery-catalog metadata, every required redo sequence, backup-media access, and applicable encryption material. Recovery planning must account for the entire chain rather than only the newest datafile backup.

The following commands illustrate a whole-CDB restore and complete recovery using the current control file:

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

This is an introductory pattern, not a universal incident script. The target CDB, channels, device types, backup tags, file destinations, and recovery scope must be confirmed for the actual environment. Review each RMAN message and continue only when the preceding operation succeeds.

Assess the Failure Before Restoration

Begin with evidence rather than a memorized command sequence. Preserve relevant alert-log and storage diagnostics, then determine:

which datafiles, tablespaces, PDBs, control-file members, and online redo members are affected;
whether the current control file and SPFILE remain usable;
the DBID, database incarnation, and target CDB;
which backup pieces or image copies contain the required files;
whether every archived and online redo sequence required for complete recovery is available;
whether TDE keys, backup passwords, media-manager configuration, and storage credentials are accessible;
whether the original location can be repaired or an alternate location is required; and
the approved recovery objective and maximum service outage.

Use RMAN reporting and validation commands to examine the repository and selected backup material:

RMAN> REPORT SCHEMA;
RMAN> LIST BACKUP SUMMARY;
RMAN> RESTORE DATABASE PREVIEW SUMMARY;
RMAN> RESTORE DATABASE VALIDATE;

RESTORE DATABASE PREVIEW reports the backups RMAN expects to use. RESTORE DATABASE VALIDATE reads the selected backups without creating restored datafiles. These checks reduce risk but do not replace an isolated recovery rehearsal.

Choose the Smallest Safe Recovery Scope

ARCHIVELOG mode does not require every media failure to become a whole-database outage. RMAN can restore and recover at several scopes when the necessary backup and redo inputs exist.

Common complete-recovery scopes
Scope	Typical availability state	Use
Individual datafile	The file is offline, while unaffected files may remain available.	Restore and recover one damaged noncritical datafile.
Tablespace	The affected tablespace is offline; other tablespaces may remain online.	Recover multiple files belonging to one application area.
PDB	The affected PDB is closed while the CDB and other PDBs may remain open.	Recover files belonging to one pluggable database.
Whole CDB	The database is mounted but not open.	Recover SYSTEM, active undo, widespread file loss, or a complete storage failure.

SYSTEM tablespace and active undo failures normally require a mounted database and a broader outage. A non-SYSTEM tablespace can often be taken offline, restored, recovered, and returned online while unaffected application areas continue operating. The exact procedure depends on file status, container, storage type, and service requirements.

Recovery When the Database Is Initially Open or Closed

The database state at the time the problem is discovered affects availability, but it does not change the requirement for a complete recovery chain. If the database is open and a noncritical datafile becomes unavailable, Oracle may take that file or its tablespace offline. The DBA can keep unaffected parts of the CDB available while restoring and recovering the damaged file. The application impact then depends on which PDB, tablespace, and objects use it.

If the database is initially closed, determine whether it can mount with the current control file. A mounted database gives RMAN the structural metadata needed to restore and recover files. Do not open the database merely to reproduce an error when the known recovery procedure requires it to remain mounted. Likewise, do not use STARTUP NOMOUNT for an ordinary datafile restore when a usable control file is available.

A whole-database recovery is appropriate when damage affects SYSTEM, active undo, many datafiles, or the storage containing most of the CDB. The database remains mounted while RMAN restores and recovers the required files. A targeted recovery is appropriate only when the unaffected files can remain current and every change needed to advance the restored file is available.

PDB recovery adds another availability boundary. The affected PDB can be closed while the root and unrelated PDBs remain open, provided that the failure and recovery method support that scope. Connect with the required privileges, confirm file ownership through CDB-aware views, restore and recover the PDB or its files, and validate its services before reopening it.

These alternatives explain why the module distinguishes recovering a closed database from recovering an open database that was initially open or initially closed. The correct choice is based on damaged structures and dependencies, not on a preference for one memorized startup command.

The Control File Changes the Recovery Procedure

The current control file records database structure, datafile and redo locations, checkpoints, incarnations, and RMAN repository metadata. If one member of a multiplexed control-file set is lost but another current member survives, repair the missing member from the current copy or adjust CONTROL_FILES. Do not replace a current control file with an older backup unnecessarily.

If every current control-file copy is lost, the instance cannot mount the database. Start in NOMOUNT, establish the DBID when required, and restore an appropriate control-file autobackup or selected backup:

RMAN> SET DBID 123456789;
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT;

After a backup control file is restored, recover the whole database and open with RESETLOGS as required by the documented procedure. This is the important exception to the normal complete-recovery sequence. The need for RESETLOGS comes from using a backup control file, not from uncommitted transactions and not merely from restoring datafiles.

How Redo and Undo Produce a Consistent Database

Redo describes changes to database blocks. During recovery, Oracle rolls forward every applicable change in the redo stream, including changes made by transactions that had not committed before failure. Redo also reconstructs changes to undo blocks.

After roll-forward, transaction recovery uses undo to reverse uncommitted work. This produces transactional consistency without discarding committed changes that were preserved in the recovery chain. Undo segments are stored in undo tablespace datafiles; they are not separate operating-system recovery files.

Checkpoint information identifies where recovery must begin for each file. The control file and datafile headers record checkpoint metadata. An SCN is an ordering mechanism, not a wall-clock guarantee. RMAN and the database use this metadata to determine which backups and redo are required.

Recovery Dependencies Beyond RMAN Backups

RMAN can protect datafiles, control files, the SPFILE, and archived redo logs. A complete recovery plan must also preserve dependencies that RESTORE DATABASE does not recreate:

password files needed for applicable remote administrative connections;
TDE keystores and credentials required to decrypt data or backups;
Oracle Net, listener, service, and cluster configuration;
SBT libraries, cloud modules, wallets, and backup-destination credentials;
the DBID, backup locations, channel configuration, and recovery runbook; and
replacement storage capacity, permissions, and expected restore throughput.

Keep at least one recoverable backup copy beyond the failure domain containing the primary datafiles. A backup in the fast recovery area does not protect against a storage failure when the FRA and database files share the same failed device.

Operations performed with NOLOGGING can create another limitation. Archived redo cannot reconstruct block changes that were not fully logged. Protect affected objects with an appropriate backup after unrecoverable operations and monitor unrecoverable-change information as part of the recovery strategy.

Validate Before Returning the Database to Service

Successful completion of RECOVER DATABASE is necessary, but operational recovery is not complete until the database and applications have been verified. After the appropriate open operation:

Review RMAN output and the alert log for missing logs, corrupt blocks, file-header errors, or tempfile problems.
Confirm the CDB open mode and open each required PDB in the intended mode.
Verify datafile, control-file, and online-redo locations, especially after storage relocation.
Confirm that services, application schemas, scheduled jobs, and external integrations operate correctly.
Compare the achieved recovery endpoint with the approved recovery objective.
Document the incident, timings, commands, decisions, and corrective actions for the recovery runbook.

VALIDATE DATABASE checks the current database files for physical corruption. RESTORE ... VALIDATE checks the backup material selected for a restore. DBVERIFY can provide specialized datafile block checks, but none of these commands alone proves that the complete service can be recovered. Periodic isolated restore tests remain essential.

A new backup is especially important after an operation that opens the database with RESETLOGS or after major storage reconstruction. A normal complete recovery with the current control file does not invalidate every existing backup, but the team should resume the documented backup schedule and confirm that it protects the repaired layout.

Complete-Recovery Decision Summary

Classify the event as instance failure, media failure, logical error, or configuration failure.
Identify the affected CDB, PDB, tablespace, datafile, control-file, and redo structures.
Confirm that the required backups, archived redo, online redo, keys, and credentials are available.
Select the smallest recovery scope that safely satisfies the service requirement.
Use the current control file when it remains usable; restore a backup control file only when required.
Restore the damaged files, apply all required redo, and verify that complete recovery has finished.
Open normally after complete recovery with the current control file; use RESETLOGS only when the recovery procedure requires it.
Validate the database, PDBs, applications, and revised backup strategy before declaring recovery complete.

Module Objectives

This module examines complete media recovery for an Oracle AI Database 26ai CDB operating in ARCHIVELOG mode. After completing the module, you will be able to:

Explain the implications of instance failure and media failure in an ARCHIVELOG database.
Distinguish complete recovery from point-in-time recovery.
Identify the backup, redo, control-file, startup, storage, and security dependencies required for recovery.
Describe a complete recovery operation for a mounted CDB.
Explain how a datafile, tablespace, or PDB can be recovered while unaffected database components remain available.
Select the correct database open operation after recovery.
Validate the recovered database before returning it to service.

The next lesson explains the implications of instance failure in an ARCHIVELOG database.