ORA-00600: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

wuweilong發表於2012-07-12
故障現象:
    在查詢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: (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 -----&gt 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  ----&gt 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 ;
 -> 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.
 
 
 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/20674423/viewspace-735272/,如需轉載,請註明出處,否則將追究法律責任。

相關文章