设为首页 收藏本站
查看: 410|回复: 0

[经验分享] ORA-00214 控制文件版本不一致恢复过程

[复制链接]

尚未签到

发表于 2015-11-8 12:01:33 | 显示全部楼层 |阅读模式
  该错误一般出现的原因:数据库服务器掉电等导致数据库异常中断。原因很简单:根据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. &quot;如果在线日志未损坏,则可以指定在线日志文件执行恢复&quot; “忘了重建模式是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 &quot;ORCL&quot; 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来恢复,所以基本没有问题。
  
DSC0000.jpg

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-136573-1-1.html 上篇帖子: PL/SQL developer ORA-12514: TNS: 监听程序当前无法识别连接描述符 下篇帖子: 关于程序出现ORA-04068错误的处理方法
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表