从未遇见的错误ora-00600 [3712] 恢复案例
本站文章除注明转载外，均为本站原创： 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: 从未遇见的错误ora-00600 [3712] 恢复案例
在Oracle数据库的日常维护中，我们可能经常会遇到一些从未见过的错误，甚至莫名其妙的错误。很多时候，甚至通过metalink、baidu、甚至google 都无法搜索到相关内容。这不，昨天公司南区同事让帮忙恢复的的一个客户数据库；据说是归档数据库，没有备份，重启实例后就无法打开数据库了。
我也是第一次听说这种事情，看了下居然是Oracle 11.2.0.3的数据库，还有这样起码的事情，确实有点匪夷所思。首先我们来看下是报错是什么样的。
看到这个错误。我感觉有一定似曾相识的感觉，但是有又说不来具体是什么错误。不过从错误号来看，我可以大致判断跟什么内容有关系。这里我拓展一下，对于Oracle ora-00600 错误，metalink有一篇详细的文档描述，里面对600错误后面的错误编号进行了分类。对于该文档大家务必了解下。所以现在即使我从未见过的ora-00600错误，我仍然可以第一眼就能大致判断是哪方面的问题。这里列举下：
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的时候不仅仅是需要去进行实例恢复，实例恢复完成后，需要顺利open数据库。如果我们试想是否存在这样一种场景：
假设当前我们恢复的数据库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数据库，完美收工！
补充：
1、后面我查询发现这极有可能是Oracle 11.2.0.3的bug：
Bug 16432211 : ORA-00600 [KCRFNL_3], LGWR… TERMINATING THE INSTANCE, ORA-00600 [3712]
后面我查询之前的alert log和trace 发现基本上完全一致。
Related posts: