DEV Community

umzzil nng
umzzil nng

Posted on • Originally published at oraerror.com

Oracle ORA-00211 Error: Causes and Solutions Complete Guide

#oracle #database #dba #sql

ORA-00211: Control File Does Not Match Previous Control Files

ORA-00211 is a critical Oracle database error that occurs during the MOUNT phase when Oracle detects that one or more control files do not match the others in the multiplexed control file set. Since Oracle relies on all copies of the control file being identical to guarantee database integrity, any inconsistency immediately halts the startup process. This error is most commonly seen after a hardware failure, an incorrect manual file copy, or an incomplete recovery operation.

Top 3 Causes

1. Mismatched Control File Versions After Partial Restore

When only one of the multiplexed control files is restored from a backup while others remain at a newer checkpoint, Oracle detects the version mismatch and throws ORA-00211.

-- Check current control file paths and status
SHOW PARAMETER CONTROL_FILES;

-- After mounting (if possible), verify SCN consistency
SELECT CHECKPOINT_CHANGE#, CONTROLFILE_CHANGE#, CONTROLFILE_TIME
FROM V$DATABASE;

-- List all control files and their status
SELECT NAME, STATUS FROM V$CONTROLFILE;
Enter fullscreen mode Exit fullscreen mode

2. Manual Copy Errors — Wrong File Overwriting

A common DBA mistake is accidentally copying an old or wrong control file over one of the multiplexed copies using OS-level commands. This leaves the control files with different DBIDs or timestamps.

-- Before any manual copy, always record current control file info
SELECT NAME, STATUS, IS_RECOVERY_DEST_FILE
FROM V$CONTROLFILE
ORDER BY NAME;

-- After restoring, confirm all files match by checking SCN
SELECT CONTROLFILE_SEQUENCE#, CONTROLFILE_CHANGE#
FROM V$DATABASE;
Enter fullscreen mode Exit fullscreen mode

3. Abnormal Shutdown or Hardware Failure

An unexpected power loss or OS crash can cause only some control files to be flushed to disk, leaving others in an older state. Attempting to restart without proper recovery leads to ORA-00211.

-- Check the alert log location for detailed error messages
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- Verify archive log mode (important for recovery strategy)
SELECT LOG_MODE, OPEN_MODE FROM V$DATABASE;
Enter fullscreen mode Exit fullscreen mode

Quick Fix Solutions

Fix 1: Copy the Good Control File to All Locations 

# Identify the most up-to-date control file (highest SCN)
# then copy it to all multiplexed locations (OS level)
cp /u01/oradata/orcl/control01.ctl /u02/oradata/orcl/control02.ctl
cp /u01/oradata/orcl/control01.ctl /u03/oradata/orcl/control03.ctl
Enter fullscreen mode Exit fullscreen mode 
-- Then restart the database
STARTUP MOUNT;
ALTER DATABASE OPEN;
Enter fullscreen mode Exit fullscreen mode

Fix 2: Restore Control File from RMAN Backup 

-- Connect to RMAN and restore
STARTUP NOMOUNT;

RESTORE CONTROLFILE FROM AUTOBACKUP;
-- or from a specific backup piece
RESTORE CONTROLFILE FROM '/backup/orcl/ctrl_c-12345-20240601-00';

ALTER DATABASE MOUNT;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
Enter fullscreen mode Exit fullscreen mode

Fix 3: Recreate the Control File 

-- Use a previously saved trace as a template
STARTUP NOMOUNT;

CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u01/oradata/orcl/redo01.log'  SIZE 200M,
  GROUP 2 '/u01/oradata/orcl/redo02.log'  SIZE 200M,
  GROUP 3 '/u01/oradata/orcl/redo03.log'  SIZE 200M
DATAFILE
  '/u01/oradata/orcl/system01.dbf',
  '/u01/oradata/orcl/sysaux01.dbf',
  '/u01/oradata/orcl/undotbs01.dbf',
  '/u01/oradata/orcl/users01.dbf'
CHARACTER SET AL32UTF8;

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
ALTER DATABASE OPEN RESETLOGS;
Enter fullscreen mode Exit fullscreen mode

Prevention Tips

1. Enable RMAN Control File Autobackup

Always configure RMAN to automatically back up the control file after every backup or structural change.

RMAN TARGET /
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
  TO '/backup/autobackup/ctrl_%F';

-- Also save a text recreation script regularly
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
  AS '/backup/scripts/recreate_ctrl.sql' REUSE RESETLOGS;
Enter fullscreen mode Exit fullscreen mode

2. Multiplex Control Files Across Separate Disks and Monitor Regularly

Always maintain at least 3 control file copies on separate physical disks or ASM disk groups, and schedule a weekly health check.

-- Weekly health check query
SELECT NAME, STATUS, IS_RECOVERY_DEST_FILE
FROM V$CONTROLFILE;

-- Confirm all copies are in sync
SELECT CONTROLFILE_SEQUENCE#, CONTROLFILE_CHANGE#,
       TO_CHAR(CONTROLFILE_TIME, 'YYYY-MM-DD HH24:MI:SS') AS CF_TIME
FROM V$DATABASE;
Enter fullscreen mode Exit fullscreen mode

Related Errors

  • ORA-00202 – Control file identity error, often seen alongside ORA-00211.
  • ORA-00205 – Error identifying control file; typically indicates a missing or corrupt file.
  • ORA-00214 – Control file version mismatch; very similar root cause to ORA-00211.
  • ORA-01122 – Database file verification failure, which can cascade from control file issues.

📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.

Top comments (0)