ORA-00600: problem with internalerrorcode, arguments..

ORA-00600: problem with internal error code, arguments..
the
Symptoms:
When querying the wwl005 table, an internal error is reported. We just performed inconsistency recovery for this table, and then the following error is reported in the query. This phenomenon is generally caused by bugs or bad blocks.
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], [], [], [], []
Analysis failure:
First check the alert log and find that there is an error, but it is not clear:
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], [], [], [], [] www.2cto.com
the
Then check the corresponding trace file to see:
[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: [email protected] (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: www.2cto.com
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 www.2cto.com  
————————————————– —————
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 High Water 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–
From the above information, we can briefly see that it is an SQL error, so which object does it correspond to? Take a look:
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
the
The explanation given by Metalink is as follows:
Summary of Bugs Containing ORA – 00600[kcbz_check_objd_typ_3] [ID 466049.1]
————————————————– ——————————
Modified 20-DEC-2009 Type REFERENCE Status PUBLISHED
www.2cto.com
In this Document
Purpose
Scope
Summary of Bugs Containing ORA – 00600[kcbz_check_objd_typ_3]
the
————————————————– ——————————
Applies to:
Oracle Server – Enterprise Edition – Version: 9.2.0.8 to 10.2.0.4
Information in this document applies to any platform.
the
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 buffer cache (BH) and on disk .
the
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
www.2cto.com
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
the
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.
Work around:
sql>alter system flush buffer cache’ to flush the buffer in the cache.
Patch Details:
Check Metalink for Patch 4430244 availability.
the
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: www.2cto.com
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
the
Workaround: –
Do not use direct path (APPEND or PQ) in a multi-table insert SQL
Check Metalink for Patch 4592596 availability.
the
Unpublished Bug 5754708 —-> Closed as Duplicate of Unpublished Bug 4996133
Abstract: ORA-600 [KCBZ_CHECK_OBJD_TYP_3] FROM “SYS.DBMS_STATS”
the
Fixed version : 9.2.08 ,A203, B106
the
Symptoms :-
www.2cto.com
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
the
Workaround:
Flush the buffer cache (10g onwards)
or
Restart the instance to clear its buffer cache.
Check Metalink for Patch 4996133 availability.
the
Bug 5348204
Abstract: ORA-600 [KCBZ_CHECK_OBJD_TYP_3] IMPORTING TRANSPORTABLE TABLESPACE FROM 10.1
the
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
the
Workaround: –
Check Metalink for Patch 4331909 availability.
www.2cto.com
Bug 5689412
the
ORA-600 [kcbz_check_objd_typ_3] after SCN
the
Symptoms :-
the
1> Primary and Standby Configuration
the
2>ORA-600 [kcbz_check_objd_typ_3] after SCN based recovery to SCN just before
a TRUNCATE operation.
the
Example
On primary
create table y (d date, v varchar2(30));
insert into y values ​​(SYSDATE, & # 39; test1 & # 39;);
insert into y values ​​(SYSDATE, & # 39; test2 & # 39;);
truncate table y;
the
Recover the standby to a point just prior to the truncate to recover this specific table. (Detemine the SCN by mining the redo)
www.2cto.com
recover standby database until change ;
-> media recovery completes successfully
the
alter database open read only;
select * from y;
^
ORA-600 [kcbz_check_objd_typ_3]
the
Workaround:-
the
Check Metalink for Patch 5689412 availability.
the
the
Author wuweilong

ck_objd_type_3]
2.Call Stack:- kcbz_check_objd_typ kcbzib kcbgtcr ktecgsc ktecgetsh ktecgshx ktsscd_segment ktsscf_segment kdicpsc kdicrws
the
Workaround: –
Check Metalink for Patch 4331909 availability.
www.2cto.com
Bug 5689412
the
ORA-600 [kcbz_check_objd_typ_3] after SCN
the
Symptoms :-
the
1> Primary and Standby Configuration
the
2>ORA-600 [kcbz_check_objd_typ_3] after SCN based recovery to SCN just before
a TRUNCATE operation.
the
Example
On primary
create table y (d date, v varchar2(30));
insert into y values ​​(SYSDATE, & # 39; test1 & # 39;);
insert into y values ​​(SYSDATE, & # 39; test2 & # 39;);
truncate table y;
the
Recover the standby to a point just prior to the truncate to recover this specific table. (Detemine the SCN by mining the redo)
www.2cto.com
recover standby database until change ;
-> media recovery completes successfully
the
alter database open read only;
select * from y;
^
ORA-600 [kcbz_check_objd_typ_3]
the
Workaround:-
the
Check Metalink for Patch 5689412 availability.
the
the
Author wuweilong