ORA-00214 控制文件版本不一致恢复过程
该错误一般出现的原因：数据库服务器掉电等导致数据库异常中断。原因很简单：根据oracle db运行原理，数据库在运行期间，由于检查点发生等原因会不断的更新控制文件，同时数据库在关闭和重启过程中都会更新控制文件的内容，但是数据库服务器突 然的掉电，会导致当前的db信息无法适时更新到控制文件中，再次启动数据库后，当oracle检测控制文件和其它文件信息是否一致时，就出现了这个错误。
错误现象：在mount数据库时，会跑出如下错误：ORA-00214: controlfile '/home/oracle/oradata/item/control01.ctl' version 10232896 inconsistent with file
'/home/oracle/oradata/item/control02.ctl' version 9190433
由于Oracle中三个控制文件互为镜像关系，正常情况下三个文件的内容是一致的，但是由于突然掉电会有可能导致三个文件没有完全同步，而出现了数据不一致的情况。数据库在mount时，会加载并检查这三个文件（Oracle根据初始化参数文件中的设定来决定检查几个参数文件）和数据文件的SCN的一致性。
下面总结一下处理过程：
尝试1：三个控制文件中若有一个控制文件的SCN是与数据文件的SCN保持一致，即可以正常将数据库启动，此时，只需要将其他两个文件从Oracle的初始化参数文件中的设定中移除即可。
[oracle@spreader oracle]$ sqlplus /nolog
[uniread] Loaded history (2158 lines)
SQL*Plus: Release 10.1.0.2.0 - Production on Mon Feb 27 11:37:09 2006
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> connect / as sysdba
SQL> startup mount
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162275532 bytes
Database Buffers 25165824 bytes
Redo Buffers 524288 bytes
ORA-00214: controlfile '/home/oracle/oradata/item/control01.ctl' version 10232896 inconsistent with file
'/home/oracle/oradata/item/control02.ctl' version 9190433
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning and Data Mining options
[uniread] Saved history (2163 lines)
SQL> create pfile='/home/oracle/init.ora' from spfile;
File created.
编辑init.ora，把'/home/oracle/oradata/item/control02.ctl'去掉，然后再重启数据库
[oracle@spreader oracle]$ sqlplus /nolog
SQL> connect / as sysdba
Connected to an idle instance.
SQL> create spfile from pfile='/home/oracle/init.ora';
SQL> startup nomount
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162275532 bytes
Database Buffers 25165824 bytes
Redo Buffers 524288 bytes
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00214: controlfile '/home/oracle/oradata/item/control01.ctl' version 10232896 inconsistent with file
'/home/oracle/oradata/item/control03.ctl' version 9190433
再编辑init.ora，把'/home/oracle/oradata/item/control03.ctl'去掉，然后再按照上面步骤重启数据库
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162275532 bytes
Database Buffers 25165824 bytes
Redo Buffers 524288 bytes
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00227: corrupt block detected in controlfile: (block 175, # blocks 1)
ORA-00202: controlfile: '/home/oracle/oradata/item/control01.ctl'
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01507: database not mounted
唯一的控制文件都有问题了，重新编辑init.ora文件，去掉控制文件一，而留下控制文件二和三，然后再重启数据库
尝试二：如果三个控制文件的SCN都与数据文件不一致了，在上面的尝试中，选择一个可以正常mount的控制文件，然后尝试打开数据库，结果抛出如下错误（此时，可选择其他其他两个文件尝试）：
ORA-01207: file is more recent than control file - old control file
尝试recover database using backup controlfile;也会抛出上述错误；
出现这个错误的意思是控制文件比数据文件的版本旧，也即数据文件中的SCN比控制文件中的SCN高；（原因请参考文章开头）。
尝试三：出现上述错误时，可以尝试通过recover database；命令来恢复数据库，使得控制文件和数据文件的SCN恢复到一致。但是oracle抛出如下错误：
SQL> RECOVER DATABASE;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
再尝试用recover database using backup controlfile to cancel;命令来恢复，可尝试指定在线日志文件的方式，具体方法参考下面。；
一旦恢复成功，则可以通过open resetlogs的方式打开数据库。
尝试四：如果依然失败，且无法打开数据库，那么此时尝试重建oracle控制文件。重建控制文件可以在数据库到mount状态下执行alter database backup controlfile to trace；生成.trc文件，该文件在$ORACLE_HOME/admin/dbname/udump/*.trc，然后根据这个文件中的内容，制作一个重建控制文件的脚本.sql文件。
在重建控制文件时，要注意以下：
第一:
要弄清楚resetlogs与noresetlogs的区别
norestlogs，控制文件的scn是来自当前日志的high scn，而resetlogs控制文件的scn是来自数据文件。我在这里开始没有弄明白，我以noresetlogs进行恢复没有问题，后来才知道为什么noresetlogs可以成功，而resetlogs没有成功。(问题：如何确定是数据文件的SCN高，还是当前日志的SCN高？)
第二:
1. 如何时取得创建控制文件的脚本，方法如下：
sql>alter database backup to trace;
通过上述命令，生成类似orcl_ora_5724.trc脚本中可以找到创建控制文件的两种方式noresetlogs/resetlogs.
2. 从.trc文件中找出如下内容，复制到create.sql文件中：
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/orcl/redo01.log' SIZE 50M,
GROUP 2 '/u01/app/oracle/oradata/orcl/redo02.log' SIZE 50M,
GROUP 3 '/u01/app/oracle/oradata/orcl/redo03.log' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/orcl/system01.dbf',
'/u01/app/oracle/oradata/orcl/undotbs01.dbf',
'/u01/app/oracle/oradata/orcl/sysaux01.dbf',
'/u01/app/oracle/oradata/orcl/users01.dbf',
'/u01/app/oracle/oradata/orcl/example01.dbf'
CHARACTER SET AL32UTF8
;
生成create.sql文件；
3. 在sqlplus中关闭数据库，并执行此create.sql文件。
SQL> @E:\create.sql
Control file created.
4.alter database mount; 把数据库启动到mount状态
5.SQL> recover database;
ORA-00283:恢复会话因错误而取消
ORA-01610:使用BACKUP CONTROLFILE选项的恢复必须已完成
因为采用的resetlogs方式，所以会出现如上的错误
这时需要用如下的方式进行恢复
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 6432534 (在 06/22/2008 16:39:31 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_06_22\O1_MF_1_13_%U_.ARC
ORA-00280: 更改 6432534 (用于线程 1) 在序列 #13 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
在这里有几个选项
suggested:在上面ORA-00289: 建议:....会按这个文件去恢复
filename:自己指定日志文件
auto:自动选择，但我个人觉得好像和suggestted一样呢:(
cancel:这个可以不从介质恢复。
我在这里选择auto和suggested无不行，报的错误如下：
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: 无法打开归档日志 'E:ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_06_22
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
采用cancel报如下错：
ORA-01112: 未启动介质恢复
经过以上的步骤后来发现：
我这里的归档日志中要求的是日志文件不存在
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_06_22O1_MF_1_9_45W1NQDP_.ARC
ORA-00310: 归档日志包含序列 9; 要求序列 10
ORA-00334: 归档日志:
'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_06_22O1_MF_1
_9_45W1NQDP_.ARC'
查看日志文件：
select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------ ---------- ---------- ---------- ---------- --- --------
1 1 0 52428800 1 YES UNUSED
3 1 0 52428800 1 YES CURRENT
2 1 0 52428800 1 YES UNUSED
发现这里的理解有问题，因为采用的是resetlogs，所以日志文件肯定是unused的。
6. "如果在线日志未损坏，则可以指定在线日志文件执行恢复" “忘了重建模式是resetlogs，你的在线日志还在吧 ，把在线日志的路径输入，比如这样D:ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG ，你把所有的日志测试过去，有一个应该是能用来做恢复”
经过再次尝试终于成功了
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 6432534 (在 06/22/2008 16:39:31 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_06_22\O1_MF_1_13_%U_.ARC
ORA-00280: 更改 6432534 (用于线程 1) 在序列 #13 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
ORA-00310: 归档日志包含序列 12; 要求序列 13
ORA-00334: 归档日志: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG'
已应用的日志。
完成介质恢复。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
数据库已更改。
到这里，由停电导致的数据库突然中断，从而引起的控制文件不一致的问题，已经全部解决了。
由于重新用resetlogs打开了数据库，所以必须在第一时间对数据库做一次完全备份。
下面，引申一下，上述我们是用resetlogs模式重建的控制文件，下面我们模拟用noresetlogs的方式来重建控制文件并打开数据库。
模拟出错的过程shutdown abort 来进行关闭据库。
第四 : 利用 noresetlogs 来进行控件文件以及数据库的恢复
1. 启动到数据库为 nomount 状态
sql>startup nomount;
2. 开始创建控制文件
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG' SIZE 50M,
GROUP 2 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG' SIZE 50M,
GROUP 3 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF',
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF',
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF',
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF',
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF',
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS02.DBF',
CHARACTER SET ZHS16GBK
;
3.recover database; // 恢复数据库
4. 打开数据库 alter database open;
因为 noresetlogs 是用当前日志的 high scn 来恢复，所以基本没有问题。