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.
 

 
 

点赞