Oracle AI Database 26ai: Open Recovery from an Initially Closed Database

Understand the Difference Between Recovery Scenarios

The traditional explanation is to mount, isolate eligible damage, open usable data, restore and recover the offline file, and bring it online. The modern example below applies that purpose across separate CDB and PDB states.

This is a teaching description of a recovery scenario, not a special RECOVER command or a deprecated backup technique. Media recovery reconstructs affected datafiles. Online backups, standby databases, and performance repositories serve other purposes and do not make this recovery scenario obsolete.

Confirm That Partial Availability Is Possible

Assume a single-instance ARCHIVELOG primary CDB with usable root, seed, and other essential files. The current control file and startup configuration survive. A suitable backup and sufficient recovery information are available, including surviving online redo when needed.

The worked branch assumes the CDB root can open while APPPDB remains mounted, and APPPDB can then open after file 12 is taken offline. SYSTEM, SYSAUX, active undo, tempfiles, control-file loss, standby recovery, and RAC procedures are outside this example.

If another damaged file prevents the proposed opening, reassess the recovery scope. A database that started closed does not automatically qualify for this method. The decisive question is whether the usable database scope can operate with the identified file offline.

Confirm administrative access, backup-media availability, restore capacity, storage permissions, and required encryption keys or backup passwords. Choose the operational sequence according to the incident; do not shut down a working database merely to reproduce this lesson's starting state.

Partial availability is an operational choice. Identify which services can perform useful work without the damaged file and which should remain unavailable. A database that accepts connections can still be unsuitable for an application whose normal transactions all depend on objects in that file.

Discuss the expected recovery duration and application dependencies with the service owner. If unaffected functions provide useful access, reopening them can reduce the practical impact of the incident. If every important function depends on the missing data, keeping application access restricted may be clearer while recovery proceeds.

The recovery plan should therefore establish both technical eligibility and the intended service benefit. Record which PDBs and services should open, which data remains unavailable, and how completion will be checked. These decisions make the opening steps purposeful and prevent the successful execution of OPEN from becoming the only measure of progress.

Step 1: Mount the CDB and Diagnose the Failure

sqlplus / as sysdba

STARTUP MOUNT

SELECT con_id, file#, name, status
FROM v$datafile
WHERE file# = 12;

SELECT file#, error, online_status, change#, time
FROM v$recover_file;

Step 2: Open the Usable CDB Root

Once diagnosis establishes that root opening is appropriate, issue the following in the root SQL*Plus session:

ALTER DATABASE OPEN;

The instance may perform automatic instance recovery as needed after the outage. That activity is distinct from restoring and recovering the damaged application file. Successful root opening does not establish that APPPDB or file 12 is available.

Inspect the actual PDB states:

SELECT con_id, name, open_mode
FROM v$pdbs;

Saved state can reopen PDBs when the CDB restarts. Other PDBs may remain mounted. Open only the intended usable PDBs under the operational plan; an unconditional ALL OPEN command does not resolve a missing-file problem.

The next step assumes APPPDB is still mounted. If it is already open, keep that useful state and isolate the affected file there. If opening reports errors, inspect which container and file they concern before deciding how to continue.

Step 3: Isolate the File and Open APPPDB

ALTER SESSION SET CONTAINER = APPPDB;
SHOW CON_NAME

ALTER DATABASE DATAFILE 12 OFFLINE;

ALTER PLUGGABLE DATABASE OPEN;

Step 4: Restore the Offline File with RMAN

Confirm the storage repair, destination capacity, and backup access before restoration. The main example uses the original recorded filename. Open another terminal in the configured CDB environment and connect RMAN to CDB$ROOT:

rman target /

The earlier SQL*Plus container switch changed only that SQL*Plus session. It does not select the target container for this new RMAN connection. Verify the target and ensure file 12 is the offline file identified during diagnosis.

Restore the affected file:

RESTORE DATAFILE 12;

RMAN selects a suitable backup using its repository and available backup access. It retrieves an earlier physical copy of the datafile. The file must remain offline because that copy still needs recovery before it can participate in normal database operations.

Preserve healthy current datafiles, the current control file, and surviving online redo. One damaged USERS datafile does not require restoring every file in the tablespace or the whole CDB.

If the original destination cannot be reused, plan a relocation with the corresponding metadata update. RMAN SET NEWNAME and SWITCH support suitable relocation workflows. Restoring somewhere new without updating the recorded location leaves the database pointing at the wrong file.

A backup listing alone does not prove that backup media is readable. Use appropriately scoped restore preview or validation when needed to resolve uncertainty. Preview examines repository information; restore validation reads backup contents without writing the restored datafile.

Step 5: Recover the Restored File

After RESTORE succeeds, continue in the root-connected RMAN session:

RECOVER DATAFILE 12;

RECOVER advances the restored copy using the required recovery information. RMAN can use applicable incremental backups and restore required archived redo from accessible backups. Surviving online redo may contain additional required changes.

Use a session without an earlier point-in-time restriction such as SET UNTIL. Complete recovery has a different objective from deliberately selecting an earlier database state. Keep the file offline until recovery reports success.

Recovery by file number permits root-connected RMAN to address a PDB datafile. If using tablespace names instead, select the appropriate PDB connection because tablespace names can repeat across containers. See Oracle's complete recovery guide.

Review the recovery output before moving on. An accessible directory containing several archived logs is not proof that the full required recovery path exists. If recovery stops, diagnose the reported dependency and preserve the current state while resolving it.

Step 6: Return the File Online and Verify Service

After successful recovery, return to SQL*Plus in APPPDB. Confirm the container and bring the recovered file online:

SHOW CON_NAME
ALTER DATABASE DATAFILE 12 ONLINE;

The CDB and APPPDB are already open. There is no second CDB OPEN step and no RESETLOGS step in this successful complete-recovery example.

Inspect the recovered file and its header in the PDB:

SELECT d.file#, d.name, d.status, h.recover, h.error
FROM v$datafile d
LEFT JOIN v$datafile_header h
  ON h.file# = d.file#
WHERE d.file# = 12;

Expected evidence includes ONLINE status, no reported header recovery requirement, and no header error. Investigate missing header information rather than treating a NULL produced by the outer join as proof of health. Combine the result with recovery completion and alert-log review.

Test representative application operations involving the recovered file and confirm intended services. Block-level checks and file status do not establish business correctness. Successful recovery means the file meets the requirements for returning online, not that every database file has an identical header SCN.

Example: Reopen Service Before a Long Restore

Suppose an overnight outage stops the instance and damages storage holding one application datafile. The root's essential files and current control file remain intact. The application file has a usable backup, but retrieving it from backup media will take time.

After mounting and diagnosing, the DBA opens the root. APPPDB remains mounted because its affected file is not usable. The DBA switches to APPPDB, takes the identified file offline, and opens the PDB using its remaining available files.

This can make selected application functions available before the restore finishes. A report whose objects occupy only healthy files may work, while another function that reads the offline file remains unavailable. The benefit depends on actual application dependencies.

RMAN restores and recovers the offline file from a separate root connection. Throughout that work, the file remains isolated. The DBA returns it online only after successful recovery, then checks the previously unavailable application functions.

The important milestones are therefore separate: root opening, PDB opening, file restoration, file recovery, and file availability. Recording each milestone helps operators describe the incident accurately and prevents a partial return of service from being mistaken for complete recovery.

Alternative: User-Managed File Restoration

A valid physical backup copy can be restored with an appropriate operating-system or storage utility while the affected file remains offline. Confirm the backup's validity, destination, and permissions. SQL*Plus cannot extract a datafile from an RMAN backup set.

After restoring the copy and updating any changed filename through the appropriate procedure, a suitably privileged SQL*Plus session in APPPDB can apply redo:

RECOVER AUTOMATIC DATAFILE 12

AUTOMATIC selects expected archived-log filenames. It does not retrieve backups or guarantee that no prompt will occur. For staged archived logs, use SET LOGSOURCE or a RECOVER FROM clause as separate alternatives. These settings do not change where newly filled online logs are archived.

After successful media recovery, use the matching ONLINE operation and verification. This is an alternative restoration/recovery method, not extra work to perform after the RMAN procedure has succeeded. Oracle's user-managed recovery procedures explain additional scopes.

Resolve Problems at the Correct Scope

Complete the Recovery Record and Backup Checks

Reconcile application requests with uncertain outcomes before asking users to retry. A committed operation whose confirmation was lost can be duplicated by blind resubmission. Verify database and application evidence for the affected work.

Resume scheduled backup protection and assess whether the incident requires additional backups under policy. Confirm that repaired storage, relocated files, media access, and encryption credentials are covered by the recovery procedure.

Retain required archived redo and remove staging copies only under the applicable deletion policy. Record the target container and file, backup source, final filename, recovery outcome, and application checks. Avoid blanket cleanup commands in shared temporary directories.

The next lesson concludes the module and reviews the complete-recovery scenarios.