Oracle RMAN
Control File Restore
Step-by-Step Guide
Oracle Database 19c
• RMAN Recovery
The Oracle control file is a
critical binary file that records the physical structure of the database. If
the control file is lost or corrupted, the database cannot be mounted or
opened. Oracle RMAN provides three methods to restore the control file:
|
# |
Method |
When to Use |
|
1 |
Restore from
RMAN backup piece |
You have the
exact backup file path |
|
2 |
Restore from
autobackup |
AUTOBACKUP is
enabled and available |
|
3 |
Re-create
from trace file |
No RMAN
backup exists; trace was previously generated |
📝 Note: Always start RMAN with 'rman target /' and start the instance in
NOMOUNT before restoring the control file.
Prerequisites
•
Oracle software installed and environment variables set
(ORACLE_SID, ORACLE_HOME, PATH)
•
RMAN backup of the control file exists (for Methods 1
and 2)
•
Trace file generated via ALTER DATABASE BACKUP
CONTROLFILE TO TRACE (for Method 3)
•
Database must be started in NOMOUNT mode before
restoring the control file
•
Sufficient disk space at the control file destination
paths
Method 1: Restore Control File from RMAN
Backup Piece
Use this method when you have a
specific .rman backup file on disk.
Step 1: Connect
to RMAN
Open a terminal as the oracle user
and connect to RMAN targeting the local database instance.
Step 2: Start
the Instance in NOMOUNT Mode
The database must be in NOMOUNT
state to restore the control file. This starts the instance using the
SPFILE/PFILE only - no control file is needed at this stage.
📝 Note: If the instance is already started in NOMOUNT, skip this step.
Step 3: Restore
the Control File from the Backup Piece
Specify the full path to the RMAN
backup piece that contains the control file. RMAN will restore it to the
locations defined in the SPFILE (DB_CREATE_FILE_DEST or control_files
parameter).
After the control file is
restored, mount the database so RMAN can read it.
Restore all datafiles from backup,
then apply archived logs to bring the database to a consistent state.
Step 6: Open
the Database
Open the database. If online logs
are available use NORESETLOGS; if not, use RESETLOGS.
📝 Note: After RESETLOGS, a new incarnation starts. Take a full backup
immediately.
Method 2: Restore Control File from
Autobackup
Use this method when CONTROLFILE
AUTOBACKUP is configured and enabled.
If you know the exact autobackup
file path, specify it directly:
Step 3: Option
B — Let RMAN Search for the Autobackup Automatically
If the exact path is unknown, use
a RUN block. RMAN searches the Fast Recovery Area (and the configured format
location) scanning backwards day by day for up to 7 days.
📝 Note: SET DBID is required when no recovery catalog is used and the
control file is not yet available. Find the DBID in the alert log or previous
RMAN output.
Step 4: Mount,
Restore, Recover and Open
Follow the same Steps 4–6 from
Method 1 to complete the recovery.
Method 3: Re-create Control File from
Trace
Use this method when no RMAN backup
exists but a trace file was previously generated.
Step 1: Generate
a Trace File (Preventive -Do This While DB is Open)
This step should be run on a
healthy database as a preventive measure. It writes a SQL script to the trace
directory that can recreate the control file.
📝 Note: Run this after every structural change: adding datafiles,
tablespaces, redo log groups, etc.
Step 2: Review
the Trace File - Choose NORESETLOGS or RESETLOGS
The trace file contains two SQL
blocks. Choose the appropriate one based on log availability:
|
Scenario |
NORESETLOGS |
RESETLOGS |
|
Online redo
logs |
✅ Available
and intact |
❌ Lost or
corrupted |
|
RECOVER
DATABASE |
RECOVER
DATABASE |
RECOVER
DATABASE USING BACKUP CONTROLFILE |
|
Open database |
ALTER
DATABASE OPEN |
ALTER
DATABASE OPEN RESETLOGS |
Step 3: Start Instance in NOMOUNT
Copy the relevant SQL block from
the trace file and run it in SQL*Plus:
Step 5: Recover
and Open the Database
After the control file is created,
recover the database using archived logs:
Step 6: Add
Temp Files to Temporary Tablespaces
Temp files are not backed up and
must be re-added manually after recovery:
Post-Recovery Checklist
•
Verify all datafiles are online: SELECT file#, status,
name FROM v$datafile;
•
Verify all PDBs are open: SELECT name, open_mode FROM
v$pdbs;
•
Check for any invalid objects: SELECT count(*) FROM
dba_objects WHERE status = 'INVALID';
•
Verify archived log gaps: SELECT * FROM v$archive_gap;
•
Take a new full RMAN backup immediately after recovery
•
Regenerate the controlfile trace: ALTER DATABASE BACKUP
CONTROLFILE TO TRACE;
•
Confirm RMAN autobackup is still enabled: SHOW ALL; in
RMAN
Quick Reference: Which Method to Use?
|
Situation |
Recommended
Method |
Key Command |
|
Backup piece
path is known |
Method 1 |
RESTORE
CONTROLFILE FROM '..path..' |
|
AUTOBACKUP
enabled, path unknown |
Method 2
(Option B) |
RESTORE
CONTROLFILE FROM AUTOBACKUP |
|
AUTOBACKUP
known path |
Method 2
(Option A) |
RESTORE
CONTROLFILE FROM 'c-DBID-date-seq' |
|
No RMAN
backup; trace file exists |
Method 3 |
CREATE
CONTROLFILE REUSE DATABASE ... |