转载

一个ORA-00600问题的简单分析(r12笔记第18天)

在前些天尝试使用sysbench来压测Oracle,没想到初战就不顺利，因为初始化几百万数据库，竟然一个小时过去了，一个表的数据都没有初始化好，这个可让我大大失望，所以我就强制清理了会话，把数据初始化流程给终止了。

今天想继续试试，看看能不能优化一些地方。但是刚开始跑初始化数据的脚本的时候，就抛出了一个ORA-00600的错误。

错误信息如下：

Creating table 'sbtest1'...
FATAL: OCIStmtExecute failed in drv_oracle.c:736
ALERT: Error - ORA-00600: internal error code, arguments: [ktsscrsegfmt:objdchk_kcbnew_3], [0], [87534], [4], [], [], [], [], [], [], [], []
FATAL: failed query was: 'CREATE TABLE sbtest1 (
id INTEGER NOT NULL,
k INTEGER,
c CHAR(120) DEFAULT '' NOT NULL,
pad CHAR(60) DEFAULT '' NOT NULL,
PRIMARY KEY (id)
) '
FATAL: failed to execute function `prepare': (null)这可就奇怪了，对于这个问题，我认为有几个可能性。

尝试1

首先这个错误是在创建表的时候失败，是不是数据库用户层面偶什么设置导致，但是查看了一圈，没有发现这个用户的特别之处，因为单独执行这条语句是没有任何问题的。

尝试2

那有没有和回收站有关呢，我的印象中清理里面的数据时，最后是使用了purge recyclebin的操作。这个操作会不会有影响呢。首先我使用和不适用purge recyclebin或者purge object，错误信息依旧存在。而有些文章中说和回收站有一定的关系，这一点上对于当前的这个问题，我还是存在疑惑，如果直接禁用，还需要重启数据库，我想继续看看有没有其它的可能性再尝试重启。

alter system set recyclebin=off
*
ERROR at line 1:
ORA-02096: specified initialization parameter is not modifiable with this
option

尝试3

我初步怀疑是否和这个用户下存在的数据情况有关，是否这个用户因为之前回滚了一个长时间的事务而导致，但是我重建了一个用户，继续运行初始化数据库脚本，依旧是同样的错误。

尝试4

问题到了这一步，我开始怀疑是否是坏块捣乱，但是查看了几个坏块相关的视图，还是没有发现任何端倪。

尝试5

这个时候我们不能猜测了，而需要看看日志，看看错误代码的特定含义，这样对我们分析问题还是大有裨益。于是我切换到了万能的MOS，错误代码是ktsscrsegfmt:objdchk_kcbnew_3

有些场景下的错误代码是

ORA-00600: internal error code, arguments: [ktspfmdb:objdchk_kcbnew_3], [1], [87561], [4], [], [], [], [], [], [

所以objdchk_kcbnew_3是我们分析的重点。

这个ORA-00600的参数代表什么含义呢。我们可以找到一些端倪。比如我们抓取的trace日志里面含有下面的信息。

Problem Key: ORA 600 [ktspfmdb:objdchk_kcbnew_3]
Error: ORA-600 [ktspfmdb:objdchk_kcbnew_3] [1] [87561] [4] [] [] [] [] [] [] [] []
[00]: dbgexExplicitEndInc [diag_dde]
[01]: dbgeEndDDEInvocationImpl [diag_dde]
[02]: dbgeEndDDEInvocation [diag_dde]
[03]: kcbnew [CACHE_RCV]<-- Signaling
[04]: ktspfmdb []
[05]: ktspfmtrng []
[06]: ktspfsall []
[07]: ktspfsrch []
[08]: ktspscan_bmb []
[09]: ktspgsp_main []
[10]: kdisnew []
[11]: kdisnewle []
[12]: kdisle []
[13]: kdiins0 []
[14]: kdiinsp []
[15]: kauxsin []
[16]: qesltcLoadIndexList [SQL_Execution]
[17]: qesltcLoadIndexes [SQL_Execution]
[18]: qerltcNoKdtBufferedInsRowCBK [SQL_Execution]
[19]: qerltcSingleRowLoad [SQL_Execution]
[20]: qerltcFetch [SQL_Execution]
[21]: insexe [DML]ORA-00600后面12个参数，上面从[4]~[15]就是和12个参数的具体调用方式，通过这种方式我们可以找到一些有用的信息,比如末尾的DML可以基本看出是在做一个DML操作，实际上是一个insert操作时抛出的错误。

比如我们可以根据87561基本猜出这是一个object_id,看看参数中代表的是ktspfsall,我们在trace里面很快就能找到一个调用堆栈。

----- Abridged Call Stack Trace -----
ksedsts()+465<-kjzdssdmp()+267<-kjzduptcctx()+232<-kjzdpcrshnfy()+43<-kstdmp()+282<-dbkedDefDump()+10974<-ksedmp
()+41<-ksfdmp()+69<-dbgexPhaseII()+1764<-dbgexExplicitEndInc()+755<-dbgeEndDDEInvocationImpl()+769<-dbgeEndDDEIn
vocation()+52<-kcbnew()+19602<-ktspfmdb()+410
<-ktspfmtrng()+1114<-ktspfsall()+1843<-ktspfsrch()+343<-ktspscan_bmb()+509<-ktspgsp_main()+1428<-kdisnew()+279
----- End of Abridged Call Stack Trace -----可以从trace里面看到有两个不同的object_id,为什么会出现这种情况，我们使用grep的方式来看一下,上面的报错是object_id 87561,这个地方是object_id 87358，后面提示了是INDEX

$ grep obj: /U01/app/oracle/diag/rdbms/perftest/perftest/incident/incdir_3805/perftest_ora_13217_i3805.trc
dbwrid: 0 obj: 87358 objn: 87358 tsn: 4 afn: 4 hint: f
seg/obj: 0x1553e csc: 0x00.11b7fd itc: 2 flg: E typ: 2 - INDEX
dbwrid: 1 obj: 87358 objn: 87358 tsn: 4 afn: 4 hint: f
seg/obj: 0x1553所以得到的一个基本的信息就是在DML插入数据需要维护索引，但是在这个过程中抛出了错误，实际上87358这个OBJECT_ID是不存在的，这个问题也有可能有多重原因触发，其中一种原因是并发，也是文档中说的比较多的。

有些朋友会碰到这类错误，比如：

alter index oraaud.NN_PARA_RES_INDEX1 rebuild parallel 4 nologging;?至于原因，用metalink中的解释来说：

In metalink, it describes as that a cache buffer holding a database block is in the process of being reused. The buffer is in state “current” and may be reused only if the object is of type temp or undo. The consistency check comparing the block class in the buffer header with the block class passed to the cache by the caller is failing.
当然这个问题如果规避，下面提出了两个相关的链接：

ORA-600 [kcbnew_3] [ID 204512.1]
Bug 6970071 – ORA-600 [kcbnew_3] when recyclebin is active [ID 6970071.8]

其实这个时候我们感觉还是有点隔靴搔痒的感觉，因为毕竟还是有些东西不够明确，我们可以肯定的是这是一个bug.

尝试6

我最后启用了重启大法，然后再次尝试就没有问题了。这个结果多具有黑幽默的感觉。但是确实如此，后续我又模拟了手工杀掉会话，可能事务还不够大，反复尝试都没有再复现这个问题，所以简单来说和回收站还是不大相关，和用户还是不大相关。