ORA-00600 [kcbgcur_9]的处理

我的一个应用系统库因为online换ibm shark硬件出现了ORA-00600 [kcbgcur_9]，此文章供大家出现同样问题的一个参考。

[@more@]

1、报错平台

操作系统	Aix 4.3.3
数据库版本	Oracle 9.2.0.3
其它	没有归档方式的备份

2、问题描述

1	IBM的阵列出现了硬件故障，在更换过程中由于执行的是online操作，且数据库是Open的。在更换硬件完毕后，发现数据库Select操作没有问题，部分表空间如：TS_FACT_GSM，DML操作报Ora-00600的错。
2	检查Alert日志，发现N多的ORA-00600: internal error code, arguments: [kcbgcur_9]。
3	应用无法正常运行。

3、我的诊断流程

(1) 检查Alert日志，发现了如下的N多的报错：

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

ORA-00600: internal error code, arguments: [kcbgcur_9], [3636461570], [13], [4294965488], [4096], [], [], []

(2)查Metalink，可以参见Doc ID为: 114058.1的这个文档，部分摘抄如下：

Note: For additional ORA-600 related information please read Note 146580.1

PURPOSE:

This article discusses the internal error "ORA-600 [kcbgcur_9]", what

it means and possible actions. The information here is only applicable

to the versions listed and is provided only for guidance.

ERROR:

ORA-600 [kcbgcur_9] [a] [b] [c] [d]

VERSIONS:

versions 8.0 to 10.0

DESCRIPTION:

Buffers are pinned in a specific class order to prevent internal deadlocks.

This exception means there is a class violation with the current

buffers pinned in the wrong class order, or duplicate buffers of

the same class.

May occur with an ORA-372 error when trying to update read-only

tablespace or partition via direct load.

ARGUMENTS:

Arg [a] The Database Block Address (DBA)

Arg [b] The buffer class

Arg [c] Block class order mask

Arg [d] Block class checking mask

如上我们可以知道这个报错的[a]部分代表的的是DBA,如下我们就对[kcbgcur_9], [3636461570]中的[3636461570]进行一下转换，把它转成file_id及block_id

通过SELECT tablespace_name FROM dba_data_files WHERE file_id=867　可以查到867属于表空间TS_FACT_GSM。

但是我们同样注意到这个DBA的block id为2，同时TS_FACT_GSM又是本地管理的表空间，由些我们知道，损坏的是本地表空间的Bitmap。

(3) 为进一步确认损坏Bitmap表空间的数量，执行了如下的查询：

SELECT COUNT(*) FROM DBA_LMT_FREE_SPACE WHERE TABLESPACE_ID = “NNN”

其中的“NNN”代表各个表空间的 TS#

4、 解决办法

(1)为保证万无一失，在操作之前要对出问题的表空间做备份，exp就可以。

(2) 以immediate方式关闭数据库，关闭Listener，把数据库重新启动到Open。

(3) SQL>execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('TS_FACT_GSM')；

如果提示过程执行成功，那就没问题了，或可以用SELECT COUNT(*) FROM DBA_LMT_FREE_SPACE WHERE TABLESPACE_ID = “NNN”再进行一下确认。

(4) 其它处理方法

其它我们可以通过重建出现问题的表空间这种办法来解决这种问题，只不过是如果数据量特别大的话，比如T级，那处理起来时间就是一个问题。同时还要提示一下的是，如果用这种方法，Drop tablespace的时侯一定要加入Including contents。

5、改善建议

(1)在做存储及的硬件的维修的时侯，如果数据库可以停掉的话最好停掉，不要报有侥幸的心理。

(2)这个问题的产生是由于Oracle的BUG：2747873，所以在建设之初选一个稳定的版本很重要，不要追求最新。可以的话急时的进行数据库版本的升级。

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

转载于:http://blog.itpub.net/717880/viewspace-812969/