【故障處理】初始化資料時報600錯誤kcbz_check_objd_typ_3

secooler發表於2010-05-04
記錄一下這個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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章