ORA-00214 错误处理

补充：一般建议使用3个控制文件，且最好做多路复用。若磁盘已经做Raid（已是多路复用），可不用将控制文件放在不同路径下。

原因：

数据库服务器掉电等导致数据库异常中断。oracle数据库在运行期间，由于检查点发生等原因会不断的更新控制文件，同时数据库在关闭和重启过程中都会更新控制文件的内容，当数据库服务异常中断时，可能会导致控制文件内容未能及时，再次启动数据库时，当oracle检测多份控制文件的信息不一致时，会报这个错误。

现象：

mount 数据库时，提示如下错误：

ORA-00214: control file '/oracle/app/oradata/test/control01.ctl' version 1841
inconsistent with file '/oradata/oracle/recovery_area/test/control02.ctl' version 1838

说明：

由于初始化参数文件中control_files 参数的配置如下：

control_files='/oracle/app/oradata/test/control01.ctl','/oradata/oracle/recovery_area/test/control02.ctl'

两个控制文件互为镜像，正常情况下两个文件的内容是一致的，但是由于突然掉电会有可能导致两个文件没有完全同步，而出现了数据不一致的情况。
数据库在 mount 时，会加载并检查这两个文件（Oracle 根据初始化参数文件中的设定来决定检查几个参数文件）和数据文件的 SCN 的一致性。

---

解决方法：

情况1： 两个控制文件中有一个控制文件的 SCN 与数据文件的 SCN 保持一致

假设本例中控制文件 /oracle/app/oradata/test/control01.ctl 的 SCN 与数据文件的 SCN 一致（control01.ctl 的版本较新），此时有两种解决方法：

1） 修改初始化参数文件

将另一个文件（/oradata/oracle/recovery_area/test/control02.ctl）从 Oracle 的初始化参数文件中的设定中移除。

SQL> SQL> create pfile='/oradata/oracle/inittest.ora' from spfile;
File created.

$ vi inittest.ora

修改 control_files=’/oracle/app/oradata/test/control01.ctl’
（补充说明：原则为保留 SCN 版本一致的控制文件，如果有多个版本一致的控制文件，也可以保留多个）

2） 修改控制文件
 
在nomount状态下执行以下操作：

• 将原 /oradata/oracle/recovery_area/test/control02.ctl 删除或重命名；

• 拷贝 /oracle/app/oradata/test/control01.ctl 至 /oradata/oracle/recovery_area/test 目录下，并重命名为 control02.ctl 。

选择任一方式处理完成后，重启数据库即可。

SQL> shutdown immediate;
ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup;
ORACLE instance started.

Total System Global Area 2.0401E+11 bytes
Fixed Size                  7657184 bytes
Variable Size            3.0065E+10 bytes
Database Buffers         1.7341E+11 bytes
Redo Buffers              529211392 bytes
Database mounted.
Database opened.

 
情况二： 如果两个控制文件的版本一致，但控制文件 SCN 与数据文件 SCN 不一致

选择一个可以正常 mount 的控制文件，然后尝试打开数据库，此时会抛出如下错误：

ORA-01207: file is more recent than control file - old control file

这个报错说明控制文件比数据文件的版本旧，也即控制文件的 SCN 比数据文件的 SCN 低。

该情况的处理方式如下：

1） 在 mount 模式下生成 trace 文件，用于控制文件重建。
说明：若已有可用的 trace 文件，可省略此步骤。

SQL> alter database backup controlfile to trace; //生成的 trace 文件默认存放在 udump 的最新 trc 文件里

或

SQL>alter database backup controlfile to trace as '/oradata/oracle/recovery_area/test/con.trace'; //存到指定的文件里

2） 正常关闭数据库，shutdown immediate 后删除控制文件
3） 利用 trace 文件重新生成控制文件
在 nomount 状态下执行 trace 脚本

SQL> startup force nomount 
ORACLE instance started.

$ vi /oradata/oracle/recovery_area/test/con.trace

复制 con.trace 文件种的有效内容执行,例如：

SQL> 
CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS ARCHIVELOG 
MAXLOGFILES 16 
MAXLOGMEMBERS 3 
MAXDATAFILES 100 
MAXINSTANCES 8 
MAXLOGHISTORY 292 
LOGFILE 
GROUP 1 '/oracle/app/oradata/test/redo01.log' SIZE 50M, 
GROUP 2 '/oracle/app/oradata/test/redo02.log' SIZE 50M, 
GROUP 3 '/oracle/app/oradata/test/redo03.log' SIZE 50M 
-- STANDBY LOGFILE 
DATAFILE 
'/oracle/app/oradata/test/system01.dbf', 
'/oracle/app/oradata/test/sysaux01.dbf',
'/oracle/app/oradata/test/user01.dbf', 
'/oracle/app/oradata/test/undotbs01.dbf' 
CHARACTER SET ZHS16GBK 
; 

也可将上述脚本部分 copy 到新建脚本文件中，然后执行脚本文件重建控制文件。例如：

• 将上述有效内容复制到 create.sql 文件并保存在 /oracle/app/oradata/test 路径下；
• 执行此 create.sql 文件

SQL> ./oracle/app/oradata/test/create.sql

Control file created.

此时若进入/oradata/oracle/recovery_area/test 路径下，会看到新建的 2 个控制文件。

说明：
 
重建控制文件的过程主要包含两部分：
【1】脚本中的可见信息：a.定义了几个参数的最大值; b.在线日志的物理信息; c.数据文件的物理信息; d.使用的字符集。
【2】隐含的不可见信息：比如 SCN 信息，重建的关键点是将当前所有数据文件头部的最新 SCN 信息复制到了控制文件中。为了接下来能够打开数据库。
 
resetlogs 与 noresetlogs 的区别：
norestlogs：控制文件的 SCN 来自 Redo log 的 high SCN；
resetlogs：控制文件的 SCN 来自数据文件；将日志序列重置，以前的归档日志就作废了。

如果你有一颗好奇的心，想看看当前控制文件和数据文件的 SCN 是否一致，可以通过如下命令查询：

SQL> select file#,checkpoint_change# from v$datafile; //查看控制文件 SCN 信息
SQL> select file#,checkpoint_change# from v$datafile_header; //查看数据文件 SCN 信息

4） 启动数据库

SQL> alter database open; 

不出意外的话，此时便可以正常启动数据库啦。

---

参考文章：https://blog.csdn.net/whhitgen/article/details/7688475