该错误一般出现的原因:数据库服务器掉电等导致数据库异常中断。原因很简单:根据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来恢复,所以基本没有问题。