ORA-00600 [kcbz_check_objd_typ_3]错误一例

5月26日凌晨某客户实例警告日志中出现”ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []“,经过分析发现与之前CR实例发生的600错误情况症状相同。

从跟踪文件m1_m0001_4209.trc中可以看到当时的执行的SQL语句,如附件。

PL/SQL的调用堆栈为:

—– PL/SQL Call Stack —–

object      line  object

handle    number  name

3f3e89300        10  package body SYS.PRVT_HDM

3f5e9d3d8        16  SYS.WRI$_ADV_HDM_T

3f3f90898      1535  package body SYS.PRVT_ADVISOR

3f3f90898      1618  package body SYS.PRVT_ADVISOR

3f3e89300       106  package body SYS.PRVT_HDM

3eb69a3f8         1  anonymous block

函数调用堆栈为:

kgerinv kgeasnmierr kcbassertbd3 kcbz_check_objd_typ kcbzib kcbgtcr ktrget kdsgrp kdsfbr qertbFetchByRowid rwsfcd…….

以上信息与metalink Bug 4430244 中的描述完全一致,原因为Segment advisor的代码错误的将已被drop的对象数据块加载到缓存区中,导致后续的操作出现错误。

通过之前的调查已明确当前系统中已应用过Bug 4430244的补丁,认为可能是ORACLE没有解决但存在的未知BUG,或者是以前 提供的4430244补丁存在缺陷,原因如下:

1. 已确定目前所应用的小补丁没有冲突,即各小补丁所实现的功 能不受影响;

2. 当前数据库系统已经使用了与本次错误信息完全符合的bug 4430244的小补丁;

3. 当相关的小补丁都应用之后,在metalink上仍有客户提交完全相同的错误(详见bug 7032704和bug 6818725)。

4. 本次错误相关的数据块与以前(2008年7月)出现的不一致,因此不是物理存储上的损坏。

5. 本次错误与Bug 6388743 “ORA-00600 [KCBZ_CHECK_OBJD_TYP_3],[0],[0],[1],[],[],[],[] OCCURRED”中的描述完全一致,ORACLE猜测是但没有确定是BUG 4430244, 只是建议使用4430244的小补丁或10.2.0.4的补丁包, 最后此bug以客户应用10.2.0.4补丁包而被视 为结束。真实原因不明。

Metalink在之前该实例出现错误的SR提出以下解决方法:

1. 在RAC的所有实例中冲 刷buffer_cache

使用命令刷数据缓存区后,会使缓存区的数据块都标记为free,即以前缓存的数据都被移出内存。影响主要是在一段时间内使物理读增加,因 此建议在业务空闲时段操作,避免在刷缓存的同时有高负载应用在申请缓存空间。该方法可临时防止相关错误抛出。

2. 停用Segment advisor job

该job相关功能是进行 对象段(如表,索引等)的存储空间状态收集,识别 是否适合根据其可用空间大小进行收缩,并提供建议,例如是否存在较大的浪费空间,表的高水位线是否太高,是否需要进行表的回缩等。如 不需要或不关心对象段的存储空间状态,可不做相关操作。该方法可以长远解决问题的发生。

3. 升级数据库版本至10.2.0.4

author: maclean
permanent link:https://www.askmac.cn/2010/05/31/ora-00600-kcbz_check_objd_typ_3%E9%94%99%E8%AF%AF%E4%B8%80%E4%BE%8B/
date:2010-05-31
All rights reserved.


Posted

in

by

Tags:

Comments

3 responses to “ORA-00600 [kcbz_check_objd_typ_3]错误一例”

  1. maclean Avatar

    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 Avatar

    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 Avatar

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *