【故障处理】初始化数据时报600错误kcbz_check_objd_typ_3

记录一下这个ORA-00600 kcbz_check_objd_typ_3错误的处理过程。

1.故障场景
1）在创建测试表T后初始化数据过程中出现的错误
sec@ora10g> create table t as select * from all_objects;

Table created.

sec@ora10g> insert into t select * from t;

11679 rows created.

sec@ora10g> /

23358 rows created.

sec@ora10g> /

46716 rows created.

sec@ora10g> /
/

93432 rows created.

sec@ora10g> /
/
/
insert into t select * from t
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []


sec@ora10g> insert into t select * from t
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []


sec@ora10g> insert into t select * from t
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []


sec@ora10g> insert into t select * from t
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []

2）alert文件中记录的内容如下
Errors in file /oracle/app/oracle/admin/ora10g/udump/ora10g_ora_16903.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Tue May  4 06:36:51 2010
Errors in file /oracle/app/oracle/admin/ora10g/udump/ora10g_ora_16903.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Tue May  4 06:38:17 2010
Errors in file /oracle/app/oracle/admin/ora10g/udump/ora10g_ora_21429.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []
Tue May  4 06:38:20 2010
Errors in file /oracle/app/oracle/admin/ora10g/udump/ora10g_ora_21429.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []
Tue May  4 06:38:23 2010
Errors in file /oracle/app/oracle/admin/ora10g/udump/ora10g_ora_21429.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [9], [0], [16], [], [], [], []
Tue May  4 06:38:25 2010

3）在警告文件中也没有太多好的提示信息，进一步查看trace文件。
*** 2010-05-04 00:43:46.991
*** ACTION NAME:() 2010-05-04 00:43:46.991
*** MODULE NAME:(SQL*Plus) 2010-05-04 00:43:46.991
*** SERVICE NAME:(SYS$USERS) 2010-05-04 00:43:46.991
*** SESSION ID:(530.544) 2010-05-04 00:43:46.991
Hex dump of (file 5, block 2459)
Dump of memory from 0x00000000609BA000 to 0x00000000609BC000
0609BA000 00000000 00000000 00000000 00000000  [................]
        Repeat 355 times
0609BB640 00000000 00000000 00010000 A2000000  [................]
0609BB650 099E0000 00000000 00000000 AE9E0501  [................]
0609BB660 00000000 00000000 00000000 00000000  [................]
  Repeat 153 times
Corrupt block relative dba: 0x0140099b (file 5, block 2459)
Fractured block found during buffer read
Data in bad block:
 type: 0 format: 0 rdba: 0x00000000
 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000000
 check value in block header: 0x0
 block checksum disabled
Reread of rdba: 0x0140099b (file 5, block 2459) found same corrupted data
*** 2010-05-04 06:36:44.699
*** SESSION ID:(530.544) 2010-05-04 06:36:44.699
OBJD MISMATCH typ=35, seg.obj=0, diskobj=87568, dsflg=0, dsobj=87569, tid=87569, cls=4
Formatted dump of block:
buffer tsn: 5 rdba: 0x014009a3 (5/2467)
scn: 0x0000.1c6b6406 seq: 0x01 flg: 0x04 tail: 0x64062301
frmt: 0x02 chkval: 0x0635 type: 0x23=PAGETABLE SEGMENT HEADER
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000006491A000 to 0x000000006491C000
06491A000 0000A223 014009A3 1C6B6406 04010000  [#.....@..dk.....]
06491A010 00000635 00000000 00000000 00000000  [5...............]
06491A020 00000000 00000001 00000008 00000A9C  [................]
06491A030 00000000 00000008 00000008 014009A9  [..............@.]
06491A040 00000000 00000000 00000000 00000005  [................]

在trace文件中记录了这个故障的真实原因，原来是“出现了坏块”Corrupt block relative dba: 0x0140099b (file 5, block 2459)。

2.确定损坏的数据块相关信息
sys@ora10g> col OWNER for a10
sys@ora10g> col SEGMENT_NAME for a10
sys@ora10g> col TABLESPACE_NAME for a15
sys@ora10g> select owner,segment_name,segment_type,tablespace_name from dba_extents where file_id = 5 and block_id between 2000 and 2459;

OWNER      SEGMENT_NA SEGMENT_TYPE       TABLESPACE_NAME
---------- ---------- ------------------ ---------------
SEC        T          TABLE              TBS_SEC_D
SEC        T          TABLE              TBS_SEC_D
SEC        T          TABLE              TBS_SEC_D
SEC        T          TABLE              TBS_SEC_D
SEC        T          TABLE              TBS_SEC_D

这个结果是显然的，因为这个故障正是我在初始化T表数据的过程中出现的。

3.确定坏块文件对应的数据文件及表空间信息
sys@ora10g> col file_name for a40
sys@ora10g> select FILE_ID,FILE_NAME,TABLESPACE_NAME from dba_data_files where FILE_ID=5;

   FILE_ID FILE_NAME                                TABLESPACE_NAME
---------- ---------------------------------------- ---------------
         5 /oracle/oradata/ora10g/tbs_sec_d_01.dbf  TBS_SEC_D

4.“暴力”处理方法
之所以说暴力处理方法，是因为，这里损坏的数据文件报错的都是测试数据，丢失后对系统没有影响。
简单重建表空间及可完成问题的处理。

1）确定表空间TBS_SEC_D仅包含此一个数据文件
sys@ora10g> select FILE_ID,FILE_NAME,TABLESPACE_NAME from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';

FILE_ID FILE_NAME                                TABLESPACE_NAME
------- ---------------------------------------- ---------------
      5 /oracle/oradata/ora10g/tbs_sec_d_01.dbf  TBS_SEC_D

2）重建表空间TBS_SEC_D
（1）删除表空间
sys@ora10g> drop tablespace TBS_SEC_D including contents and datafiles;

Tablespace dropped.

（2）如此时对应的数据文件没有连带删除，可执行手工删除
sys@ora10g> !rm -f /oracle/oradata/ora10g/tbs_sec_d_01.dbf

（3）创建表空间TBS_SEC_D
sys@ora10g> create tablespace TBS_SEC_D datafile '/oracle/oradata/ora10g/tbs_sec_d_01.dbf' size 50m;

Tablespace created.

到此，问题处理完毕。

5.小结
本文中描述了一种坏块处理方法。
不过这种方法的确是简单粗暴的方式，在生产库中一定要“酌情”。
最佳恢复坏块方法当然是使用有效地备份进行恢复（切记：备份是DBA的第一梯队救命稻草）。

Good luck.

secooler
10.05.04

-- The End --

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

转载于:http://blog.itpub.net/519536/viewspace-661905/