一個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

我最後啟用了重啟大法，然後再次嘗試就沒有問題了。這個結果多具有黑幽默的感覺。但是確實如此，後續我又模擬了手工殺掉會話，可能事務還不夠大，反覆嘗試都沒有再復現這個問題，所以簡單來說和回收站還是不大相關，和使用者還是不大相關。