Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 808
  • Last Modified:

Oracle database control file inconsistent!

I had to rebuild a mirror and now I am receiving this error when I try to start the database

ORA-00214: controlfile '/db02/RDI/cntrl_02.dbf' version 118513789 inconsisten
t with file '/db01/RDI/cntrl_01.dbf' version 117606173
2 Solutions
dfkeSr. Systems EngineerCommented:
The control file "string" version string is inconsistent with file "string" version string. The set of redo log files, datafiles and multiplexed control files must be consistent. So they must have the same internal sequence number for Oracle to start up or shut down the database.

As you know, the control file is the 'memory' of a database that contains also the identification of the datafiles. In other words you just added to your database a control file that is not consitent with the datafile (that '.dbf') you have into the database. You will probably get the same message about all datafile (it stopped to the first it has checked).

Where did you get that control file from ? Do you have a consistent backup (control file & data files with the same scn ?)

Check the control file mamagement docs here for info on how they work, how you should backup and multiplex them, how to recreate them when all are lost :

The controlfiles of a database must always be secured (backuped) the same way as your data does.

johnsoneSenior Oracle DBACommented:
Based on your description, it sounds like /db01 is the file system you lost and restored from a mirror copy.  If that is true then this should be helpful.

How confident are you in the mirror?  If you are confident that the mirror is intact then you should be able to recover from this.  The SCNs reported in the control files are radically different, but that could just be how far apart your checkpoints are.

If you are 100% sure your mirror is intact.  You should be able to do the following:

TAKE A BACKUP OF EVERYTHING THE WAY IT CURRENTLY EXISTS.  This step cannot be stressed enough.  If something goes wrong you can at least get back to where you are.

The first thing you need to do is get the control files in sync.  That is pretty easily done by copying /db02/RDI/cntrl_02.dbf into /db01/RDI/cntrl_01.dbf.

At this point, you should be able to do a STARTUP MOUNT.  Then a RECOVER DATABASE.  That should bring everything back into sync.  As long as all the archives are still on the system you shouldn't have to restore anything.  If during the recover it asks for an archive one past all the archives you have, specify the online file.  If you aren't sure which one is current, just try them in order.  If you give the incorrect online log it will tell you and it doesn't harm anything, just do the RECOVER DATABASE again and specify the next one.  Realistically if you look at the date stamp on the online logs you should be able to determine which one is the current one.

Featured Post

[Webinar On Demand] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now