故障处理：ORA-00600: internal error code, arguments: [kcbgcur_6]

        早晨刚来公司，开发就电话过来说一个重要的开发环境宕机了，请我们来恢复！起初只是知道数据库启动（startup）报告如下错误：

ORA-00355: change numbers out of order
ORA-00353: log corruption near block 59377 change 24089191279 time 03/27/2011 22:38:00
ORA-00312: online log 3 thread 1: '/oradata/udbprod/oradata_d0/UDBPROD/onlinelog/o1_mf_3_5gojv3q5_.log'
ORA-355 signalled during: ALTER DATABASE OPEN...

数据库处于非归档模式（所有开发环境为了管理简单化，节省空间，所以都是非归档模式），是10.0.4.0的版本，从报错看貌似是日志文件错误，所以第一意识想到的办法resetlogs重建日志组的方式打开数据库，完成恢复。紧接着发现失败了！

经过ORA-00355错误，查询matelink资料发现如下方案：

Disable incremental checkpoints for thread recovery.
The incremental checkpoint may be advanced even though there are still buffers in the cache with a low RBA before the checkpoint. This can lead to unexpected errors during recovery.

_disable_incremental_checkpoints = true

设定了上述参数，数据库终于打开不报错了！但是过1-2分钟库自动就宕机了，这时候开始看oracle的告警日志（alert_.log）文件，报错如下

Tue Mar 29 18:15:05 2011
Errors in file /oracle/admin/udbprod/udump/udbprod_ora_15625.trc:
ORA-00600: internal error code, arguments: [kcbgcur_6], [65537], [4294967295], [0], [0], [], [], []

发现其实早期的宕机就是这个报错引起的，这是oracle内部错误，查询oracle的matelink正好有这个错误的描述。smon进程去清理undo回滚段发现未知错误。起因是当undo回滚段的segment过度扩展数量大于32759时，库就会宕机，报告这个ORA-600错误。经过查询undo的segment正好是32759个

matelink提供了一个唯一的方案，设定10061事件和打patch包来解决，考虑到matelink方案的复杂性，我和另一个dba分析后每人给出一个自己的解题方案。

我首选自己的方案，undo重建，替换掉原来的undo。执行后发现，create undo的过程容易出发对旧undo的检查，所以创建总失败！我把创建undo的size尺寸给的很小，在试过几次后终于创建成功，但是系统因为有数据不一致，在open库后依然会出发数据同步报错undo错误。此方案失败

另一个dba的建议是禁用smon检查的打开db，但是库是无法使用的，所以依然不是正确的方案。

下面只能按照matelink的说明打patch了：

1）设定10061事件参数，启动数据库。

event="10061 trace name context forever, level 10"

此事件将预防smon进程清理临时表空间段。

2）

下载应用oracle补丁：Patch 7410816

不包含这个事件的状态下重启instance

(patch does contain fix to cleanup segment + restrict no of undo segments)

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23652549/viewspace-697842/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23652549/viewspace-697842/