数据库

img hrb_qiuyb

ORA-00600 [kcbgcur_9]的处理

发表于2005/12/21 10:51:00  2385人阅读

1、  报错平台

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

 

2、  问题描述

1
IBM的阵列出现了硬件故障,在更换过程中由于执行的是online操作,且数
据库是Open的。在更换硬件完毕后,发现数据库Select操作没有问题,部分
表空间如:TS_FACT_GSMDML操作报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_idblock_id
通过SELECT tablespace_name FROM dba_data_files WHERE file_id=867 可以查到867属于表空间TS_FACT_GSM

但是我们同样注意到这个DBAblock id2,同时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)    这个问题的产生是由于OracleBUG2747873,所以在建设之初选
一个稳定的版本很重要,不要追求最新。可以的话急时的进行数据库版本的升级。
阅读全文
0 0

相关文章推荐

img
取 消
img