ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

故障现象：
在查询wwl005这张表的时候，报内部错误，对于这张表我们刚才是做了不一致性恢复，之后在查询报如下错误，对于这种现象一般都是由于bug或坏块引起。
15:43:53 SQL> select * from wwl005;
select * from wwl005
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

分析故障:
首先检查alert日志，发现有报错，但是不明确：
Errors in file /DBSoft/admin/WWL/udump/wwl_ora_4724.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

再检查对应的跟踪文件看看：
[root@wwldb ~]# cat /DBSoft/admin/WWL/udump/wwl_ora_4724.trc |more
Dump file /DBSoft/admin/WWL/udump/wwl_ora_4724.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /DBSoft/product/10.2.0/db_1
System name: Linux
Node name: wwldb.localdomain
Release: 2.6.18-164.el5
Version: #1 SMP Thu Sep 3 02:16:47 EDT 2009
Machine: i686
Instance name: WWL
Redo thread mounted by this instance: 1
Oracle process number: 12
Unix process pid: 4724, image: oracle@wwldb.localdomain (TNS V1-V3)

*** ACTION NAME:() 2012-07-10 15:44:04.239
*** MODULE NAME:(SQL*Plus) 2012-07-10 15:44:04.239
*** SERVICE NAME:(SYS$USERS) 2012-07-10 15:44:04.239
*** SESSION ID:(50.5) 2012-07-10 15:44:04.239
*** SESSION ID:(50.5) 2012-07-10 15:44:04.239
OBJD MISMATCH typ=35, seg.obj=0, diskobj=51698, dsflg=0, dsobj=51697, tid=51697, cls=4
Formatted dump of block:
buffer tsn: 6 rdba: 0x0140002b (5/43)
scn: 0x0000.0014adb8 seq: 0x01 flg: 0x04 tail: 0xadb82301
frmt: 0x02 chkval: 0x6296 type: 0x23=PAGETABLE SEGMENT HEADER
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x25DB2000 to 0x25DB4000
25DB2000 0000A223 0140002B 0014ADB8 04010000 [#...+.@.........]
25DB2010 00006296 00000000 00000000 00000000 [.b..............]
25DB2020 00000000 00000001 00000008 00000A9C [................]
25DB2030 00000000 00000003 00000008 0140002C [............,.@.]
25DB2040 00000000 00000000 00000000 00000000 [................]
25DB2050 000E0004 000000F4 00000001 00000000 [................]
25DB2060 00000003 00000008 0140002C 00000000 [........,.@.....]
25DB2070 00000000 00000000 00000000 01400029 [............).@.]
25DB2080 01400029 00000000 00000000 00000000 [).@.............]
25DB2090 00000000 00000000 00000000 00000000 [................]
Repeat 3 times
25DB20D0 00000001 00002000 00000000 00001434 [..... ......4...]
25DB20E0 00000000 0140002A 00000001 01400029 [....*.@.....).@.]
25DB20F0 0140002A 00000000 00000000 00000000 [*.@.............]
25DB2100 00000000 00000000 00000001 00000000 [................]
25DB2110 0000C9F2 10000000 01400029 00000008 [........).@.....]
25DB2120 00000000 00000000 00000000 00000000 [................]
Repeat 152 times
25DB2AB0 01400029 0140002C 00000000 00000000 [).@.,.@.........]
25DB2AC0 00000000 00000000 00000000 00000000 [................]
Repeat 151 times
25DB3440 00000000 00000000 0140002A 00000000 [........*.@.....]
25DB3450 00000000 00000000 00000000 00000000 [................]
Repeat 185 times
25DB3FF0 00000000 00000000 00000000 ADB82301 [.............#..]
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 8
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x0140002c ext#: 0 blk#: 3 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
Disk Lock:: Locked by xid: 0x0004.00e.000000f4
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x0140002c ext#: 0 blk#: 3 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
Level 1 BMB for High HWM block: 0x01400029
Level 1 BMB for Low HWM block: 0x01400029
--------------------------------------------------------
--More--

从如上信息我们可以初略的看到是SQL错误，那么对应的是哪个对象呢，看看:
16:03:17 SQL> select object_id, data_object_id, owner, object_name, object_type from dba_objects where data_object_id in (51698, 51697) or object_id in (51698, 51697);

OBJECT_ID DATA_OBJECT_ID OWNER OBJECT_NAME OBJECT_TYPE
---------- -------------- ----- ------------ -------------------
51697 51697 WWL WWL005 TABLE

Metalink 给出的解释如下:

Summary of Bugs Containing ORA - 00600[kcbz_check_objd_typ_3] [ID 466049.1]

--------------------------------------------------------------------------------

Modified 20-DEC-2009 Type REFERENCE Status PUBLISHED

In this Document
Purpose
Scope
Summary of Bugs Containing ORA - 00600[kcbz_check_objd_typ_3]

--------------------------------------------------------------------------------

Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.8 to 10.2.0.4
Information in this document applies to any platform.

Purpose
This article is intended to

1. Help the reader to understand ORA-600 [kcbz_check_objd_typ_3] error and how is this caused.

2. List the most common bugs of the aforesaid error and their fixes.
Scope
This is a consolidated article based upon various bugs logged for the error
ORA-600 [kcbz_check_objd_typ_3] and gives the reader an overview about the most frequent bugs which the customers are affected with.

The error ORA-600 [kcbz_check_objd_typ_3] is raised because we see different object id in bufffer cache (BH) and on disk .

Summary of Bugs Containing ORA - 00600[kcbz_check_objd_typ_3]
Bug 5466416---Closed as Duplicate of Unpublished Bug 4430244

Abstract: ORA-600 [KCBZ_CHECK_OBJD_TYP_3] ON INSERT VIA DBMS_STATS OR DBMS_SPACE

Versions affected : 10.2

Fixed releases : 10.2.0.4, 11.0.0.0

Details : Segment advisor code (eg: DBMS_SPACE.OBJECT_GROWTH_TREND)

can load blocks into the cache for Dropped objects as CURRENT leading

to subsequent operations seeing an incorrect (old) version of a block.

This can lead to various internal buffer cache related errors such as

ORA-600 [kcbnew_3] / ORA-600 [kcbz_check_objd_typ_3].

The exact error depends on which code sees the block.

Backportable : yes to 10.2

Symptoms :

1. ORA-600 [kcbnew_3] internal error reported in the alert.log

2. May occur if segment advisor and DROP operation are being run
concurrently on the same object.

Workaround :

sql>alter system flush buffer cache' to flush the buffer in the cache.

Patch Details:

Check Metalink for Patch 4430244 availability.

Bug 5859511 -----> Closed as Duplicate of Unpublished Bug 4592596

Abstract: INTERMITTENT ORA-600 [KCBZ_CHECK_OBJD_TYP_3] FROM PARALLEL SLAVES

Fixed releases : 10.2.0.4, 11.0.0.0

Details:
Corruption can occur using a multi-table insert SQL with
direct load operations. Eg: If the SQL goes parallel.
This can result in subsequent ORA-1410 type errors on selects
from the target table/s.

Symptoms :

1.Select on table fails with ORA-600 [kcbz_check_objd_typ_3] after multi-table insert with direct load was done.

2.Analyze on the table fails with ORA-1410

3.Call Stack :- kcbassertbd3 kcbz_check_objd_typ kcbzib kcbgtcr ktrget kdst_fetch kdstf0010101km
kdsttgr qertbFetch qergiFetch qertqoFetch

Workaround: -
Do not use direct path (APPEND or PQ) in a multi-table insert SQL

Check Metalink for Patch 4592596 availability.

Unpublished Bug 5754708 ----> Closed as Duplicate of Unpublished Bug 4996133

Abstract: ORA-600 [KCBZ_CHECK_OBJD_TYP_3] FROM "SYS.DBMS_STATS"

Fixed version : 9.2.08 ,A203, B106

Symptoms : -

1. Running in RAC mode
2. Reading the overflow segment of an IOT
3. Call Stack :- kdsgnp kafger qerixGetNonKeyCol qerixFetchByLogicalRowid
Or
Call Stack :- kcbassertbd3 kcbz_check_objd_typ kcbzib kcbgtcr ktrget kdsgrp kdsfbr qertbFetchByRowID

Workaround:
Flush the buffer cache (10g onwards)
or
Restart the instance to clear its buffer cache.

Check Metalink for Patch 4996133 availability.

Bug 5348204

Abstract: ORA-600 [KCBZ_CHECK_OBJD_TYP_3] IMPORTING TRANSPORTABLE TABLESPACE FROM 10.1

Fixed In Ver: 10.2.0.1

Symptoms :-

1.Cross Platform tablespace Import using Transportable tablespace option fails with following error message

ORA-39083: Object type TABLE failed to create with error
ORA-600: internal error code, arguments: [kcbz_check_objd_type_3]

2.Call Stack :- kcbz_check_objd_typ kcbzib kcbgtcr ktecgsc ktecgetsh ktecgshx ktsscd_segment ktsscf_segment kdicpsc kdicrws

Workaround: -

Check Metalink for Patch 4331909 availability.

Bug 5689412

ORA-600 [kcbz_check_objd_typ_3] after SCN

Symptoms : -

1> Primary and Standby Configuration

2>ORA-600 [kcbz_check_objd_typ_3] after SCN based recovery to SCN just before
a TRUNCATE operation.

Example
On primary
create table y (d date, v varchar2(30));
insert into y values (SYSDATE, 'test1');
insert into y values (SYSDATE, 'test2');
truncate table y;

Recover the standby to a point just prior to the truncate to recover this specific table. (Detemine the SCN by mining the redo)

recover standby database until change <SCN>;
-> media recovery completes successfully

alter database open read only;
select * from y;
^
ORA-600 [kcbz_check_objd_typ_3]

Workaround :-

Check Metalink for Patch 5689412 availability.