1、 报错平台
操作系统
|
Aix
|
数据库版本
|
Oracle
|
其它
|
没有归档方式的备份
|
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，所以在建设之初选一个稳定的版本很重要，不要追求最新。可以的话急时的进行数据库版本的升级。