ORA-00600: 内部错误代码, 参数: [17114], [0x2A97775EF8], [], [], [], [], [], []

092012

晚上吃完饭来到电脑前，刚一上线发现QQ上有人发过来消息，是之前刚认识的一名Oracle学习者，问候之后说遇到一个错误想让帮忙看下，随即让其把相关的错误信息发过来。发过来的alert日志中重要的信息如下：

Fri Jan  6 22:05:24 2012

GATHER_STATS_JOB encountered errors.  Check the trace file.

Fri Jan  6 22:05:24 2012

Errors in file /oracle/product/admin/ccyyp/bdump/ccyyp2_j002_20620.trc:

ORA-03001: unimplemented feature

… …

Sun Jan  8 13:54:04 2012

Errors in file /oracle/product/admin/ccyyp/udump/ccyyp2_ora_22998.trc:

ORA-00600: internal error code, arguments: [17114], [0x9FFFFFFFBF228800], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [17114], [0x9FFFFFFFBF228800], [], [], [], [], [], []

上面主要包含两个错误，ora-03001和参数为17114的ora-600错误。

该朋友的Oracle 版本为10.2.0.4，OS为HP-UX B.11.31 ia64。

根据上面的ORA-03001错误的提示信息可以知道是因在执行gather_stats_job时触发的ora-03001，经过查询mos发现这是一个unpublished Bug 6011068，MOS原文如下：This issue is caused by the unpublished Bug 6011068 Abstract:ORA-3001 DBMS_STATS.GATHER_TABLE_STATS which points to the base Bug 5767661 Abstract:Wrong results with function based index.

解决该问题可通过收集errorstack跟踪一下究竟是在执行什么语句时报的错，不过那位朋友已经不在线了，希望他明天可以按照我的方法再跟踪一下，应该是可以找到原因并解决该问题的。

1.  启用event 3001

SQL> alter session set max_dump_file_size=unlimited;

SQL> alter session set events ‘3001 trace name errorstack level 3’;

2.  手动执行gather_stats_job

SQL> exec dbms_scheduler.run_job(’gather_stats_job’);

3.  查看event 3001 errorstack 的trace文件

主要查看Current SQL statement for this session部分，应该会出现如下类似内容：

select /*+ parallel_index(t,"<index_name>",16) dbms_stats cursor_sharing_exactuse_weak_name_resl dynamic_sampling(0) no_monitoring no_expand…………….

4.  获取上面得到的索引的DDL语句

SQL> select dbms_metadata.get_ddl(’index’,’<index_name>’,’<schema_name>’) from dual;

5.  检查索引的DDL语句中是否为常数索引（目前我直觉上最坏这种情况）

比如：create index schema.index_name on schema_table_name(1)…之类的语句。

如果是常数索引的话，也可通过查询user_indexes数据字典视图确实该索引的类型，因为如果该索引的是常数索引的话，那么该索引的类型将是FUNCTION-BASED NORMAL类型，相当于函数索引。Oracle通常将常数索引视为一种函数索引，因为该“函数”会始终返回一个恒定的数值。

6.  如果ora-03001错误确实因为索引为常数索引所致，并且想避开此bug从而避免安装patch，可通过重建该索引并且不再使用常数索引解决（其实，常数索引并无太大用处）。

该问题在10.2.0.4版本及之前的版本中会出现，而在10.2.0.5及其之后的版本，Oracle已经对此进行了修复，本人在10.2.0.5和11g（平台包含linux/aix/hpux）版本均已测试。

下面接着看alert日志中的ora-00600错误

该错误也极可能是bug，根据传过来的trace文件发现如下信息：

*** 2012-01-08 13:53:49.003

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [17114], [0x9FFFFFFFBF228800], [], [], [], [], [], []

Current SQL statement for this session:

select * from v$session where paddr=:"SYS_B_0"

通过语句select * from v$session where paddr=:”SYS_B_0”可以知道该系统将数据库初始化参数的CURSOR_SHARING进行了改动（similar or force），默认值为exact。如果cursor_sharing参数被设置了非默认值，则Oracle会在系统级别对SQL记性Bind处理，将原有语句的常量修改为系统BIND变量SYS_B_0，SYS_B_1…等，从而达到语句共享性目的。其中similar和force有和区别呢？当设置为force时，Oracle强制进行绑定化处理，而不管语句的执行计划是否合理。而设置为similar时，Oracle会判断进行绑定化处理之后，其执行计划是否合理。

突然想起，记得这位朋友在QQ上说cursor_sharing设置为了force，那么我想该ora-600极可能是因修改cursor_sharing引起，因为cursor_sharing修改为force或者similar后，会引起诸多bug的事实已不鲜见。

个人感觉最妥当的办法是：

1.  重置cursor_sharing初始化参数为默认值

2.  从应用程序角度考虑SQL的绑定化处理（这是解决问题最核心的方式，我们都知道数据性能问题通常至少有50%的比例是因程序问题导致）

关于这个ora-600错误，相关的bug有两个bug 9158302和bug 8674660，我想将cursor_sharing重置为默认值后，该问题将会被避免。希望这位朋友看到本文后会着种考虑下。