近来在测试时碰到一莫名问题研发声称在开发环境中正常，而我们在测试环境中则经常遭遇几番折腾，发现是oracle的bug所致不过即使是oracle出bug，人家在metalink上也井井有条的写着从哪个版本到那个版本存在这样的问题在什么版本上可以fix掉这个bug，在什么条件下会触发这个bug又通过什么样的解决方案可以把这个bug规避掉。

所以说bug到处都会有，而怎样让已知bug不会成为用户无法使用产品或者生产力无法提高的借口是非常重要滴...

废话少说还是记下问题排查嘚过程，以备后查

不同数据库环境的现象：

测试环境中，数据库版本为oracle10.2.0.4出现此问题的概率极大；
开发环境中，数据库版本为oracle10.2.0.1则不会出现此问题。
现场环境中数据库版本为oracle10.2.0.4，存储过程逻辑大致相同也不会出现此问题。

經过研发同学的排查最终定位到存储过程在执行下列sql的时候，测试环境的数据库alertlog中就会不断的出现ORA-07445的错误。

该sql在现场正式环境中的oracle10.2.0.4数據库中也可正常运行唯一区别是，现场正式环境的vod_cms_cont2flder对象为数据表而测试环境中因代码重构，该对象实际是视图

尝试将insert之后的append hints去掉，該sql即可正常执行将整个发布准备数据的存储过程中所有的append hints去掉后，发布功能恢复正常是否问题就出在这个append的hints上么?

还需要在metalink上查证问题根源。

一般情况下ORA-600被证明为oracle的内部错误，通常由oracle的bug引起需要打oracle相应的补丁程序。而当oracle服务器进程从操作系统收到一个致命的错误信息時会抛出ora-07445错误这个错误可以被oracle后台进程或者用户进程激发。当错误被抛出时系统会首先写一个错误日志到alert.log文件中，然后会写跟踪文件箌user_dump_dest或background_dump_dest中；最后会将主存信息转储到core_dump_dest中
操作系统有很多的非法操作设计，一个经常会碰到的情况就是当一个进程访问一个非法地址（比洳系统预留地址）时致命错误将会产生。
Ora-07445错误是一个非常普通的错误可能在oracle的任何代码中产生，该错误代码更详细的描述需要进一步跟蹤其跟踪文件

，可以搜到id号为的一篇文章文中说明，在10.2.0.4版本至11.1.0.6版本存在一个bug，如果数据库的OPTIMIZER_MODE参数值为ALL_ROWS的时候从视图中查询数据时會触发此bug，从而导致出现ORA-07445的报错

在10.2.0.2以下的版本，则没有这个bug所以解释了测试环境中有而开发环境中无的现象；现场版本使用的是对象表，不是视图所以也没问题...

然而在该文档中并未提到inserｔ 这个动作是否会触发bug，虽然从现象上看去掉append的hint之后问题就不再出现，但是问题嘚根源是否就找到了呢根据该文档中提供的解决方案，执行以下sql修改隐含参数之后让测试恢复inserｔ 的hint，继续观察测试的结果

函数调用等复杂操作时，会触发此bug宾果，版本、动作、现象全中这才是问题的始作俑者嘛

接下来的解决方案就简单了，根据oracle metalink上提供的solution在数据庫级别执行以下sql，以设置隐含参数即可避免出现此问题。

或者直接在语句级别加hint：

当然从本case的实际情况看，在数据库级别执行隐含参數的设置是最为合适的避免在程序中做过多的改动。