RelationalDBDesign RelationalDBDesign

Physical Backups  «Prev 

Fuzzy Backup Problems in Oracle

Problem: Due to electric failure my database server went down. When I restarted it returned an ORA-00214 as shown below:
SQL> startup

ORACLE instance started.
Total System Global Area 83605532 bytes
Fixed Size 75804 bytes
Variable Size 57016320 bytes
Database Buffers 26435584 bytes
Redo Buffers 77824 bytes

ORA-00214: controlfile 'D:\ORACLE\ORADATA\DATA\CONTROL01.CTL' version 11541 
inconsistent with file 'D:\ORACLE\ORADATA\DATA\CONTROL03.CTL' version 11538

Question: Can someone help me with the solution to this ORA-00214?
Answer: The docs note this on the ORA-00214 error:
ORA-00214: control file "string" version string inconsistent with file "string" version string.
Cause: An inconsistent set of control files, datafiles/logfiles, and redo files was used.
Action: Use a consistent set of control files, datafiles/logfiles, and redo log files. That is, all the files must be for the same database and from the same time period. Typical ways to get an ORA-00214 include forgetting to replace ALL OF the current control files in all locations specified in the init.ora control_files parameter. Remember, all of the control files, in all locations, must match exactly.
All copies of the control file must have the same internal sequence number for Oracle to start up the database or shut it down in normal or immediate mode.
If the database is running and the checkpoint in the file header could not be advanced the datafile will be taken offline. Typical scenarios in which you may receive an ORA-00214 include:
  1. You have restored the control file from backup, but forgot to copy it onto all of the mirrored copies of the control file as listed in the "CONTROL_FILES" parameter in the init.ora file for this instance
  2. You have moved one or more copies of the control file to a different location while the database was up and running.
  3. You accidentally overwrote one of the copies of the control file with an old copy.
  4. The database or the system crashed while the mirrored copies of the control file were being updated, causing them to be out of sync.
  5. You are restoring a database backup that was improperly taken with the database up and running ("fuzzy" backup).

At Time T1 a backup of a datafile is in progress and the current redo log sequence is 76.

At time T2 a log switch occurs and the current redo log sequence is #77

At time T3 a data change in one transaction is affecting table 1 and table 2. The changed data for Table 1 is stored in the file.dbf. However, it is not copied into the copy of file.dbf because the read-write head already passed that area. The changes are recorded in the current redo log #77 as X1 and X2.

At time T4 the read-write head only copies change X2.

The copy of the file.dbf is in a fuzzy state because it does not contain all the information about the latest transaction . When a recovery is necessary, the redo log #77 (now written into Archive Log #77) has to be applied to restore the entire information about this latest transaction.