sitemap

RSS地图

收藏本站

设为首页

Oracle研究中心

当前位置:Oracle研究中心 > 故障案例 >

【案例】Oracle报错ora-00600 [3712]产生原因和MOS官方解决办法

时间:2016-11-12 14:02   来源:Oracle研究中心   作者:网络   点击:

天萃荷净 Oracle研究中心案例分析:运维DBA反映Oracle 11G数据库在关闭后打开时无法启动,并报错ora-00600 [3712]。结合MOS分析产生原因为数据库BUG导致,重建控制文件解决。
本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: 从未遇见的错误ora-00600 [3712] 恢复案例

客户数据库:归档数据库,没有备份,重启实例后就无法打开数据库。
Oracle 11.2.0.3的数据库



对于Oracle ora-00600 错误,metalink有一篇详细的文档描述,里面对600错误后面的错误编号进行了分类。大致判断是哪方面的问题。这里列举下:

Ora-600 Base Functionality Description
2000 server/rcv Cache Op
2100 server/rcv Control File mgmt
2200 server/rcv Misc (SCN etc.)
2400 server/rcv Buffer Instance Hash Table
2600 server/rcv Redo file component
2800 server/rcv Db file
3000 server/rcv Redo Application
3200 server/cache Buffer manager
3400 server/rcv Archival & media recovery component
3600 server/rcv recovery component
3700 server/rcv Thread component
3800 server/rcv Compatibility segment

从描述来看,我们可以大致判断,该错误肯定跟redo 有关系。我们再回头去看下alert log的信息,可以看到一行比较关键的信息:crash recovery due to error 600.

对于Oracle 数据库的open过程,我们知道需要经过nomount–mount–open这样几个过程,如果是异常关机例如强制abort的情况,那么open数据库时,Oracle 需要进行instance recovery;实际上我查询v$Log 也可以发现current redo logfile 的next_change# 为无穷大.

首先我尝试手工进行了一次recover database,没有任何问题,然后alter database open还是报上面的3712错误。这里我发现一个问题,所有的scn都已经变化,而且更新到了一致的状态。但是为啥还是报错呢?

我们知道其实Oracle open的时候不仅仅是需要去进行实例恢复,实例恢复完成后,需要顺利ohttp://www.oracleplus.netpen数据库。如果我们试想是否存在这样一种场景:

假设当前我们恢复的数据库scn已经到了100000,然而实例恢复完成后open时发现下一个要更新的scn比当前的要小(比如99999),会怎么样呢? 很明显这是会报错的。

很多人或许看不懂,甚至不理解我为什么会这样设想,这里主要有2个因素:

1、 基于对于数据库原理的基本理解,深入了解oracle数据库open的过程

2、细心观察上述的ORA-00600 错误.

ok,就拿这个错误来讲 [3371],[612688841],[3371],[612688840];当我们看到这一串数字的时候,我们应该认为或者试想这写数字都是什么含义 ?

根据我们的数据库理解和经验来判断,通常都是表示序列,dba地址,文件号,scn等等这些。

我想,稍微有一点常识的人可能都能看出来,这里应该是表示的SCN。或许有人说为什么这里会是表示的scn呢?

如果这样想,那说明你不了解Oracle scn的基本结构。Oracle 中的scn,分为高位和低位两部分组成。大致上如下:

scn最低值是0×0000.00000000,最高值是0xffff.ffffffff。高位是scn wrap,即0×0000,低位是scn base,即后面的8个位。正确的SCN应该是=scn warp * power(2,32)+scn base

能够想到这里,我想我们可以大致判断这里的3371 应该是scn wrap值,而后面的612688841应该是scn base。将scn换算一下然后和文件头的最新scn进行比较,发现完全符合。这里能够验证我们的判断。

到这里,我们可以发现一个问题,scn不对啊? 为什么不对? 因为这里出现了2个scn,分别是:

3371*power(2,32)+612688841 和3371*power(2,32)+612688840

很明显,这2个值大小不同,我想Oracle 肯定是进行判断,发现即将产生的scn比我们当前的scn还要小,才会出现这个情况。那么后面要小的scn就是有问题的scn。而这个scn 比如来源于控制文件。

想到这里,我就知道,我应该如何去完美解决这个问题了。那么答案就是重建控制文件。

如下是恢复的基本步骤,重建控制文件的步骤就不再描述了。

产生重建控制文件的脚本后,重建控制文件,记得noresetlogs 方式去创建即可(rac环境需要修改cluster_database=false);创建完毕后直接recover一把,然后顺利open数据库,完美收工!

查询发现这极有可能是Oracle 11.2.0.3的bug:

Bug 16432211 : ORA-00600 [KCRFNL_3], LGWR… TERMINATING THE INSTANCE, ORA-00600 [3712]

后面我查询之前的alert log和trace 发现基本上完全一致。

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之【案例】Oracle报错ora-00600 [3712]产生原因和MOS官方解决办法

本文由大师惜分飞原创分享,网址:http://www.oracleplus.net/arch/1242.html

Oracle研究中心

关键词:

ORA-00600

ora-00600 [3712]

Oracle数据库关闭后无法启动报错ora-00600 [3712]