Recover or Re-create a Lost Control File in Oracle 26ai

What the Control File Provides

Diagnose the Failure and Choose a Path

A control-file error can result from unavailable storage, permissions, an incorrect path, or corruption. Examine the error stack and alert log, and investigate the underlying storage problem. Check every configured copy before concluding that all current copies are lost.

From an authorized SQL*Plus session, the following checks help identify the configured locations and current instance state, including when the instance is in NOMOUNT:

SHOW PARAMETER control_files

SELECT instance_name, status
FROM v$instance;

Structural views such as V$DATAFILE are not a substitute for a saved inventory when the database cannot mount. At that point, work from preserved trace output, configuration records, backup metadata, and corroborating diagnostics.

Path 1: Replace a Damaged Copy from a Current Copy

Stop the instance before copying the surviving current control file. Repair the failed destination or select a supported replacement location, copy using tools appropriate to the storage, and ensure CONTROL_FILES identifies the intended copies before restarting. Do not copy an actively changing control file with a generic operating-system command and treat the result as a valid online backup.

A filesystem copy command is not an ASM file-management procedure. Likewise, changing a configured destination requires the appropriate SPFILE or PFILE handling. CONTROL_FILES is static, so a changed configuration must take effect through the planned restart. Preserve the existing configuration until the replacement plan is clear.

Oracle documents that replacing a failed copy from an intact current copy does not itself require media recovery. Independent datafile damage or an unclean shutdown may still have recovery consequences. See Managing Control Files.

Path 2: Restore a Binary Backup with RMAN

When no current copy survives, a binary backup provides an established starting point. It also retains information that a reconstruction script does not reproduce in full, including backup-related records. Converting a binary backup into trace SQL is not a mandatory intermediate step.

The following RMAN example assumes no recovery catalog, a known DBID, usable initialization configuration, and an accessible disk autobackup that RMAN can locate. Connect to the correct CDB target as an authorized user with SYSBACKUP or SYSDBA. Replace the illustrative DBID with the database's recorded identifier.

SET DBID 1234567890;
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RECOVER DATABASE;

Issue STARTUP NOMOUNT only if the instance is down. If it is already in NOMOUNT, continue there. Nondefault autobackup formats, older search windows, and media-manager backups require matching search or channel details. An unqualified autobackup search does not inspect every possible storage location.

Restore normally writes to the configured control-file destinations, which must be accessible. Review recovery output before proceeding. Once recovery succeeds, open with:

ALTER DATABASE OPEN RESETLOGS;

Backup-control-file recovery requires RESETLOGS even when complete recovery succeeds. This requirement alone does not mean committed changes were lost. See Performing RMAN Recovery: Advanced Scenarios.

Do not automatically restore every datafile just because the control file was restored. Usable existing files can be part of the recovery plan. Conversely, damaged files, a changed recovery target, or missing required redo need explicit treatment. The short example assumes those requirements have already been assessed.

The restored repository may predate recent backups or structural changes. If recovery requests an unknown log, investigate its identity and location and reconcile the repository as appropriate. Do not interpret the message as permission to cancel recovery and open at an unexamined boundary. Keep the intended recovery outcome separate from the availability of a particular backup.

Path 3: Re-create the Control File from Trace SQL

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

SELECT value
FROM v$diag_info
WHERE name = 'Default Trace File';

Execute the Reviewed Reconstruction Procedure

@/u02/recovery/create_controlfile_reviewed.sql

RECOVER DATABASE

ALTER DATABASE OPEN;

Account for Read-Only, Offline, and Temporary Files

A generic instruction to put every file into the DATAFILE clause is insufficient. The supplied guide describes special treatment of read-only and offline-normal files during reconstruction. Such files may be omitted under the documented procedure and later reconciled from MISSING entries. Accidentally omitting a required read/write file is a different problem.

Before renaming a MISSING entry, establish the file's identity, state, and recovery requirements. Do not assume that a filename substitution makes an unknown or damaged file usable. The next lesson develops the read-only recovery case in more detail.

Tempfiles also require separate handling. Trace output can include ALTER TABLESPACE ... ADD TEMPFILE statements for later execution. Preserve the necessary container context and verify the resulting temporary tablespaces. Tempfiles do not belong in a fabricated permanent-datafile list and are not restored like ordinary backed-up datafiles.

Keep Planned Configuration Changes Separate

Control-file reconstruction should not become a routine response to every configuration change. MAXDATAFILES initially sizes the datafile section; that section can expand within DB_FILES limits. A planned database rename should consider DBNEWID, which Oracle recommends instead of CREATE CONTROLFILE for that purpose. Both points are documented in the SQL reference.

Do not carry old sample limits, redo sizes, or paths into the recovery script simply because they appeared in a previous lesson. During an incident, preserve verified settings and restore service. Evaluate unrelated capacity or naming changes through their own planned procedures.

Verify Recovery and Protect the New Starting Point

A successful script does not prove that applications are ready. Review recovery completion messages and outstanding file requirements. Once the database is appropriately mounted or open, inspect the actual control-file locations and identity; after opening, check PDB state:

SELECT name, status FROM v$controlfile;

SELECT name, dbid, open_mode, log_mode
FROM v$database;

SELECT con_id, name, open_mode FROM v$pdbs;

A blank control-file status is not by itself an error. Correlate the results with the expected locations and diagnostics. Confirm that intended PDBs and services are available, required permanent and temporary files are accounted for, and representative application reads succeed.

Re-creating the control file does not reconstruct every RMAN repository record. Reconcile required backup and incarnation information using a recovery catalog or supported catalog and registration procedures. Earlier backups are not automatically worthless after RESETLOGS, but their usability depends on the required metadata and recovery chain.

Back up the reconstructed control file promptly. In an appropriately connected RMAN session:

BACKUP CURRENT CONTROLFILE;

Restore verified multiplexing on separate failure domains, retain binary backups and current trace SQL, and protect the SPFILE, DBID, configuration, and file inventory. A fresh database backup can provide a convenient recovery starting point. Test access to those resources before the next incident; multiple copies reduce risk but cannot eliminate every shared failure.

The next lesson describes how to recover a read-only tablespace.