Oracle AI Database 26ai Recovery Methods and Database States

Separate the Recovery Target, Scope, and State

Recovery terminology describes several different decisions. Keeping them separate makes it easier to select a procedure and understand its consequences.

• Target: Complete recovery brings affected files to the current required consistency point. Point-in-time recovery returns the selected scope to an earlier state.
• Scope: Recovery can concern a CDB, PDB, tablespace, datafile, table, or individual blocks. The supported procedure depends on that scope.
• Operating state: NOMOUNT, MOUNT, and OPEN determine which database structures are available and whether application access is possible. File and PDB states add further requirements.

For instance, complete recovery of an offline application datafile can occur in an open database. The endpoint is current, the scope is one file, and the database remains open. These descriptions complement one another; they are not competing names for the same decision.

How Database State Affects Recovery

Four Practical Recovery Scenarios

The following scenarios illustrate common choices for datafile recovery. They are useful examples rather than an exhaustive list of Oracle recovery methods.

1. Recover While the Database Is Mounted

Mounted recovery is appropriate when the recovery scope requires the database to remain closed to applications. Examples include whole-CDB datafile recovery and recovery involving critical files that cannot be isolated while the relevant database remains operational.

With a usable control file mounted, RMAN can identify files and backup records. The DBA restores the required backups, applies recovery information, and opens the database using the procedure appropriate to the recovery performed.

If the server parameter file, or SPFILE, is also lost, startup configuration must first be restored or supplied through an appropriate bootstrap procedure. Restoring an SPFILE restores initialization settings; it does not apply redo or recover application transactions. Likewise, restoring a control file provides essential database metadata but does not by itself complete datafile recovery.

The business impact may be substantial, but availability preferences cannot override file dependencies. If the database cannot safely open without the affected files, it must remain in the required recovery state until those dependencies are resolved.

2. Recover an Eligible File When the Database Is Already Open

Suppose an application datafile becomes unavailable while the database is running. If the affected file can be isolated without preventing the rest of the database from operating, take that file or its tablespace offline before restoring it.

The conceptual sequence is to isolate the affected files, restore appropriate backups, recover the files, and return them online. Application functions that depend on those files remain unavailable, even though unrelated functions may continue.

This is complete datafile recovery performed within an open database. It does not mean Oracle permits unrestricted replacement of files that applications are actively using.

3. Open Unaffected Data Before Finishing File Recovery

A failure may leave the instance stopped or prevent the database from opening because an application datafile is missing. Where the damaged files are eligible for offline recovery, the DBA can mount the database, identify and offline those files, and open the unaffected database contents if all remaining opening requirements are satisfied.

Recovery of the offline files can then proceed while unaffected work resumes. The same restore-and-recover principle applies as in the previous scenario; the difference is the starting state and the preparation required before opening.

This approach is conditional. It cannot bypass missing critical files, unresolved consistency requirements, or other startup errors. Oracle's complete database recovery guide describes procedures for the relevant recovery scopes.

4. Reconstruct a Datafile That Has No Backup

A newly added datafile might be lost before its first scheduled backup. In a limited recovery scenario, Oracle can re-create an eligible file and rebuild its contents by applying the required redo from the time of its creation.

This requires control-file metadata identifying the file and all necessary redo since its creation, including any required surviving online redo. Missing redo or changes that cannot be reconstructed because of NOLOGGING can prevent success. The ALTER DATABASE CREATE DATAFILE mechanism cannot reconstruct SYSTEM datafiles.

This advanced exception does not justify omitting backups. It can require a much longer redo history than ordinary recovery from a recent file backup. A later module examines the procedure; Oracle documents its prerequisites under re-creating datafiles when backups are unavailable.

Automatic Recovery After an Instance Failure

If the current datafiles, control files, and required online redo remain intact, an abrupt shutdown normally requires automatic instance recovery as the database opens. Oracle rolls forward recorded changes and uses undo to remove uncommitted work. Transaction rollback can continue after opening.

Both ARCHIVELOG and NOARCHIVELOG databases support instance recovery. This process does not normally require restoring a backup, manually applying archived redo, or opening with RESETLOGS.

After a clean shutdown with intact files, no instance recovery is needed. However, clean shutdown does not mean every transaction was committed: SHUTDOWN IMMEDIATE rolls back uncommitted transactions, while normal shutdown waits for sessions to disconnect. Physical file loss after either shutdown still requires separate diagnosis.

Complete Recovery and Point-in-Time Recovery

Complete media recovery applies the information necessary to bring restored files to the current required consistency point. Archived redo, applicable incremental backups, and surviving online redo may contribute. Merely applying the last log available in a directory does not establish that recovery is complete.

Point-in-time recovery deliberately returns data to an earlier consistent state. A target can identify the point before an unwanted transaction or an endpoint that remains recoverable when later required information is unavailable. Suitable backups and recovery information must support that target.

Whole-database point-in-time recovery affects the CDB and its PDBs. PDB point-in-time recovery limits the scope to an eligible PDB. Tablespace point-in-time recovery, or TSPITR, returns a supported set of tablespaces to an earlier state using an auxiliary recovery environment. Object relationships and recovery prerequisites must be considered before choosing a narrower scope.

Opening rules depend on the operation. Ordinary complete recovery using the current control file normally opens without RESETLOGS. DBPITR and recovery using a backup control file require RESETLOGS. PDB PITR reopens the affected PDB with RESETLOGS; do not apply that rule as a whole-CDB operation after TSPITR or table recovery.

Block, Table, and Flashback Recovery

Block Media Recovery

When a small number of blocks are physically corrupt, block media recovery can avoid restoring an entire datafile. RMAN repairs eligible blocks while the rest of the file remains available, although access to the affected blocks can be interrupted.

This method has specific prerequisites, including ARCHIVELOG mode and a current control file. Backup-based block recovery uses suitable full or level 0 backups and required archived redo; level 1 incremental backups cannot replace those recovery inputs. It is not a solution for a completely missing datafile.

Recovering Tables from RMAN Backups

RMAN table recovery can retrieve eligible tables or partitions at an earlier point without rewinding the entire production database. RMAN creates an auxiliary database, restores and recovers the required supporting files there, and creates a Data Pump export containing the recovered objects.

The objects can then be imported into the target, with supported remapping where needed. The target must be open read/write and use ARCHIVELOG mode. Backups, auxiliary space, and object restrictions still matter. See Oracle's table and partition recovery guidance.

Flashback and Recovery Scope

Flashback Query can inspect historical data, Flashback Table can rewind eligible tables using undo, and Flashback Drop can retrieve eligible objects remaining in the recycle bin. These operations address logical errors while the relevant database or PDB is open.

Flashback Database uses available flashback history and redo to rewind existing datafiles. Whole-CDB Flashback requires mounting the CDB. For a supported local-undo Flashback PDB operation, the CDB can remain open while the target PDB is closed; other PDBs can remain available.

Flashback requires appropriate prior preparation and reachable history. It cannot replace physical backups after datafile loss. A normal restore point names a target; a guaranteed restore point provides stronger flashback retention subject to its requirements. Neither is a backup. Oracle's Flashback and point-in-time recovery guide explains the differences.

Make Recovery Information Accessible

Check the Current State Before Choosing a Procedure

Use an appropriately privileged administrative session. The following read-only query identifies the instance state:

SELECT instance_name, status
FROM v$instance;

For the ordinary startup states, STARTED corresponds to NOMOUNT, MOUNTED identifies a mounted database, and OPEN identifies an open database. After mounting, inspect database mode:

SELECT name, open_mode, log_mode
FROM v$database;

In a CDB, use a suitably privileged connection to the root to inspect PDB states, subject to container visibility:

SELECT con_id, name, open_mode
FROM v$pdbs
ORDER BY con_id;

Combine these results with file diagnostics and the alert log. An OPEN result does not prove that all PDBs, tablespaces, or application functions are available. Conversely, a MOUNTED result alone does not explain why the database has not opened.

Backup Choices Determine Recovery Options

Choose the recovery target and affected scope first, then establish the required database, PDB, and file states. Confirm that the available backups and redo support the chosen procedure before changing those states. The next lesson describes the complete recovery operation in greater detail.