故障现象：
在查询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.
