在一個升級後的測試資料庫中發現了這兩個ORA-600錯誤資訊。

詳細的錯誤資訊為：

Errors in file /data/oracle/diag/rdbms/test9/test9/trace/test9_m000_25429.trc (incident=161):
ORA-00600: internal error code, arguments: [ktfbbsearch-8], [128], [15], [], [], [], [], [], [], [], [], []
Incident details in: /data/oracle/diag/rdbms/test9/test9/incident/incdir_161/test9_m000_25429_i161.trc
Errors in file /data/oracle/diag/rdbms/test9/test9/trace/test9_m000_25429.trc (incident=162):
ORA-00600: internal error code, arguments: [kewrose_1], [600], [ORA-00600: internal error code, arguments: [ktfbbsearch-8], [128], [15], [], [], [], [], [], [], [], [], []
], [], [], [], [], [], [], [], [], []
Incident details in: /data/oracle/diag/rdbms/test9/test9/incident/incdir_162/test9_m000_25429_i162.trc

對應的TRACE資訊為：

[oracle@bjtest trace]$ more /data/oracle/diag/rdbms/test9/test9/incident/incdir_161/test9_m000_25429_i161.trc
Dump file /data/oracle/diag/rdbms/test9/test9/incident/incdir_161/test9_m000_25429_i161.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /data/oracle/product/11.2
System name:    Linux
Node name:      bjtest
Release:        2.6.18-8.el5xen
Version:        #1 SMP Tue Jun 5 23:53:34 EDT 2007
Machine:        x86_64
Instance name: test9
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 25429, image: oracle@bjtest (M000)

*** 2010-04-29 23:17:41.653
*** SESSION ID:(48.5) 2010-04-29 23:17:41.653
*** CLIENT ID:() 2010-04-29 23:17:41.653
*** SERVICE NAME:(SYS$BACKGROUND) 2010-04-29 23:17:41.653
*** MODULE NAME:(MMON_SLAVE) 2010-04-29 23:17:41.653
*** ACTION NAME:(Auto-Flush Slave Action) 2010-04-29 23:17:41.653

Dump continued from file: /data/oracle/diag/rdbms/test9/test9/trace/test9_m000_25429.trc
ORA-00600: internal error code, arguments: [ktfbbsearch-8], [128], [15], [], [], [], [], [], [], [], [], []

========= Dump for incident 161 (ORA 600 [ktfbbsearch-8]) ========

*** 2010-04-29 23:17:41.655
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=aktbxfjwnzgmu) -----
update WRM$_DATABASE_INSTANCE set    last_ash_sample_id = :last_ash_sample_id where instance_number    = :instance_number   and db
id               = :dbid   and startup_time = (select max(startup_time)                        from   WRM$_DATABASE_INSTANCE
                 where instance_number = :instance_number2                          and dbid            = :dbid2 )

----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+36        call     kgdsdst()            000000000 ? 000000000 ?
                                                   7FFFB0079F18 ? 000000001 ?
                                                   7FFFB007E418 ? 000000000 ?
ksedst1()+98         call     skdstdst()           000000000 ? 000000000 ?
                                                   7FFFB0079F18 ? 000000001 ?
                                                   000000000 ? 000000000 ?
ksedst()+34          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFFB0079F18 ? 000000001 ?
                                                   000000000 ? 000000000 ?
dbkedDefDump()+2736 call     ksedst()             000000000 ? 000000001 ?
                                                   7FFFB0079F18 ? 000000001 ?
                                                   000000000 ? 000000000 ?
ksedmp()+36          call     dbkedDefDump()       000000003 ? 000000002 ?
                                                   7FFFB0079F18 ? 000000001 ?
                                                   000000000 ? 000000000 ?
ksfdmp()+64          call     ksedmp()             000000003 ? 000000002 ?
                                                   7FFFB0079F18 ? 000000001 ?
                                                   000000000 ? 000000000 ?

顯然這時11g的輕量級的程式m000進行一些後臺統計操作。可以看到，ORA-600(kewrose_1)錯誤實際上是另一個ORA-600(ktfbbsearch-8)錯誤導致的，這一點從報錯資訊中也可以確認。

在metalink中檢查了一下，沒有發現kewrose_1錯誤的相關資訊，導致找到一篇關於ktfbbsearch-8錯誤的文章：Bug ID 4704614。

這篇文章標題為：DATABASE WITH DB_BLOCK_SIZE=9K GIVES ORA-600[KTFBBSEARCH-8] WHEN INSERT/DELETE。這個現象和當前的環境十分類似，雖然當前資料庫的DB_BLOCK_SIZE並不是9K，但是也不是標準的2K的冪，而是10K：

[oracle@bjtest ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on 星期五 4月 30 01:00:19 2010

連線到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter db_block_size

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_block_size integer 10240

在10g以後，Oracle就不再支援非2k的冪的DB_BLOCK_SIZE了，這個資料庫是透過升級從9.2升級到11g的，因此具有這種不標準的DB_BLOCK_SIZE。

應該就是這個原因導致了系統中出現了ORA-600[KTFBBSEARCH-8]錯誤。

這種不標準的環境儘量不要應用在產品系統中，很可能導致很多bug的產生。

ORA-600(ktfbbsearch-8)和ORA-600(kewrose_1)錯誤

相關文章