在一个升级后的测试数据库中发现了这两个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的产生。

ITPub博客

ORA-600(ktfbbsearch-8)和ORA-600(kewrose_1)错误

最新文章