ORA-00600 [kcbz_check_objd_typ_3]错误一例

Comments

1. maclean says

   2010/09/02 at 23:02

   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.
    

   回复
2. maclean says

   2010/09/02 at 23:03

   ORA-600 [kcbz_check_objd_typ_3] Error from SMON Process Repeatedly
   Applies to:
   Oracle Server – Enterprise Edition – Version: 9.2.0.1 to 10.2.0.4 – Release: 9.2 to 10.2

   Symptoms
   An ORA-600 [kcbz_check_objd_typ_3] error occurs on start up of the instance from the SMON process and is repeatedly signaled in the alert log eventually leading to a PMON instance crash occurring.  Checking the trace file shows the error occurring when accessing a buffer with “seg.obj=0” and the call stack shows module ktssdt_segs() on the call stack, e.g.:

   kcbz_check_objd_typ kcbzib kcbgtcr ktecgsc ktecgetsh ktecgshx kteinicnt1 ktssdrbm_segment ktssdro_segment ktssdt_segs ktmmon ksbrdp opirip opidrv sou2o opimai_real main _start 
   Cause
   This can occur due to SMON encountering a corrupt temporary segment during temp segment cleanup, as identified by the presence of module ktssdt_segs() (Drop Temporary Segments) on the call stack.
   Solution
   Firstly, set event 10061 at level 10 in the instance to disable SMON from performing temporary segment cleanup, e.g.:

           connect / as sysdba
          
   alter system set events ‘10061 trace name context forever, level 10’;
          
   shutdown immediate
          
   startup

   This will prevent the instance from crashing at the expense of not cleaning up temporary segments, and so should only be done as a short term measure whilst the problem segment is identified and manually dropped.  To identify the problem temporary segment, locate the segment data_object_id’s, tablespace number, relative file number and data block number relating to the problem segment from the trace file, e.g.:

   OBJD MISMATCH typ=16, seg.obj=0, diskobj=66600, dsflg=0, dsobj=66598, tid=66598, cls=4
   Formatted dump of block:
   buffer tsn: 2 rdba: 0x00c01c44 (3/7236)
   scn: 0x02c8.c219172e seq: 0x01 flg: 0x00 tail: 0x172e1001
   frmt: 0x02 chkval: 0x0000 type: 0x10=DATA SEGMENT HEADER – UNLIMITED
   Hex dump of block: st=0, typ_found=1

   From the above we can tell the following:

   On disk DATA_OBJECT_ID (diskobj) = 66600
   In memory buffer DATA_OBJECT_ID (dsobj) = 66598
   Tablespace number (tsn:) = 2
   Relative file number (from translated rdba value) = 3
   Block number (from translated rdba value) = 7236

   Use the above values in the following queries to identify if the related object actually exists and gather further information relating to the segment, e.g.:

   connect / as sysdba
   select * from v$tablespace where ts# =2;
   TS# TABLESPACE_NAME
   ——- ——————————
   2 TOOLS

   select * from seg$ where file#=3 and block# = 7236;
   FILE# BLOCK# TYPE# TS# BLOCKS EXTENTS INIEXTS
   ———- ———- ———- ———- ———- ———- ——–
   MINEXTS MAXEXTS EXTSIZE EXTPCT USER# LISTS GROUPS
   ———- ———- ———- ———- ———- ———- ——–
   BITMAPRANGES CACHEHINT SCANHINT HWMINCR SPARE1 SPARE2
   ———— ———- ———- ———- ———- ———-
   3 7236 3 2 32 1 32
   1 2147483645 32 0 111 0 0
   0 0 0 66598 1

   select object_id, data_object_id, owner, object_name, object_type from dba_objects
   where data_object_id in (66598, 66600) or object_id in (66598, 66600);
   select segment_name, owner, segment_type from sys.dba_extents
   where file_id = 3 and 7236 between block_id and block_id + blocks -1;

   If the SEG$ row returned shows the segment of anything other than of type temporary (TYPE# = 3) or either of the last two queries return any rows, then stop here and report all of the above information together with the trace file and alert log to Oracle Support for further analysis.

   Otherwise this confirms the problem is due to a corrupt temporary segment and so to correct this you will need to manually drop the corrupt temporary segment, and so effectively patch the data dictionary. This is a very dangerous operation and therefore it is essential that you take a full backup of the database before proceeding further. Failure to do this could result in the complete loss of your database in the event of unforeseen problems occurring when patching the database!

   Once a backup has been taken, patch the database by executing the following using your tablespace name, file number and block number derived above, e.g.:

   connect / as sysdba
   startup restrict
   exec dbms_space_admin.segment_corrupt(‘TOOLS’, 3, 7236, DBMS_SPACE_ADMIN.SEGMENT_MARK_CORRUPT);
   exec dbms_space_admin.segment_drop_corrupt(‘TOOLS’, 3, 7236);
   exit

   Then remove event 10061 from the instance init.ora/spfile and stop and restart the instance and check for the ORA-600 [kcbz_check_objd_typ_3] error re-occurring on start up, e.g.:

   connect / as sysdba
   shutdown immediate
   startup restrict
   alter system disable restricted session;
   exit

    
    

   回复
3. maclean says

   2010/09/02 at 23:04

   Hdr: 5689412 10.2.0.3 RDBMS 10.2.0.3 BUFFER CACHE PRODID-5 PORTID-212 ORA-600
   Abstract: SELECT REPORTS ORA-600 [KCBZ_CHECK_OBJD_TYP_3] AFTER SCN BASED RECOVERY
   =========================
   PROBLEM:

   1. Clear description of the problem encountered:

   – Recover a physical standby database to a specific change number.
   – Open the standby read only.
   – A select fails with :

   ORA-600 [kcbz_check_objd_typ_3], [0], [0], [1], [],[], [], []

   2. Pertinent configuration information (MTS/OPS/distributed/etc)

   – Physical standby database.

   3. Indication of the frequency and predictability of the problem

   – Each time.

   4. Sequence of events leading to the problem

   – Ct. wants to delay application of redo to the standby to allow time to
   rectify problems on the
   primary.

   – For example, on the primary :

   SQL> create table y (d date, v varchar2(30));
   SQL> insert into y values (SYSDATE, ‘test1’);
   SQL> insert into y values (SYSDATE, ‘test2’);
   SQL> truncate table y;

   – In the above case we want to recover the standby to a point prior to the
   truncate to recover this specific table as the redo has not yet been applied
   at the standby.

   – Next step: mine the log for the above inserts/truncate to locate an
   appropriate SCN to recover to:

   SQL> select scn, sql_redo from v$logmnr_contents order by scn;

   SCN SQL_REDO
   ———- ————————————————–
   629740 insert into “UNKNOWN”.”OBJ# 11575″(“COL 1″,”COL 2”
   ) values (HEXTORAW(‘786a0b1d0b0d17’),HEXTORAW(‘746
   5737432’));

   629743 commit;
   629744 set transaction read write;
   629745
   629748 set transaction read write;
   629752 insert into “UNKNOWN”.”OBJ# 474″(“COL 1″,”COL 2″,”
   COL 3″,”COL 4″,”COL 5″,”COL 6″,”COL 7″) values (HE
   XTORAW(‘c302104c’),HEXTORAW(’80’),HEXTORAW(’80’),H
   EXTORAW(’80’),HEXTORAW(‘786a0b1d0b0d1c’),HEXTORAW(
   ‘c102′),HEXTORAW(’80’));
   629752 set transaction read write;
   629753 commit;
   629755 truncate table y;

   – In the logminer output table y is OBJ#11575.

   – Attempts at selecting from table y after recovery to either SCN ‘629753’
   (commit) or ‘629755’ (truncate table y) will trigger the ora-600.

   – On the standby:-

   SQL> recover managed standby database cancel;
   SQL> recover standby database until change ;
   -> media recovery completes successfully

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

   5. Technical impact on the customer. Include persistent after effects.

   – Unable to get copy of table at required change number.

   =========================
   DIAGNOSTIC ANALYSIS:

   – The ORA-600 trace file reports :

   OBJD MISMATCH typ=16, seg.obj=0, diskobj=11576, dsflg=0, dsobj=11575,
   tid=11575, cls=4
   Formatted dump of block:
   …

   – Where the table being selected from was obj#11575

   =========================
   WORKAROUND:

   – The standby continues fine if it’s returned to managed standby mode. But
   then the truncate has
   been applied.

   =========================
   RELATED BUGS:

   =========================
   REPRODUCIBILITY:
   1. State if the problem is reproducible; indicate where and predictability

   – Reproduced on 10.2.0.2:

   2. List the versions in which the problem has reproduced

   – 10.2.0.2

   3. List any versions in which the problem has not reproduced

   =========================
   TESTCASE:

   – See above.

   ========================
   STACK TRACE:

   kcbassertbd3
   kcbz_check_objd_typ – Check the objd and typ of buffer that has been read
   in.
   kcbzib – KCB: input buffer – reads a block from disk into a buffer

   kcbgtcr – KCB: Get a block for CR
   ktecgsc – KTE Concurrency – Get Segment header and auto-Convert
   ktecgetsh – KTE Concurrency – GET Segment Header
   ktecgshx
   kteinicnt1
   kkotabnblks
   kkedsamp

   =========================
   SUPPORTING INFORMATION:

   – alert.log and trace file with ORA-600
   – README with details for accessing a database where the error can be
   triggered.

   回复