alert 报错如下图
我看到07445，第一想到的是这个报错可是跟ORA-600一个级别的。由于是周末，打算先加强该数据库的监控，暂时先观察。发现该报错集中在每天的14点、18点、22点，报错时间段很集中。
1、分析思路：收集该时间段的ASH，追踪引起该报错的SQL的是不是跟客户业务相关，找到问题SQL（如图二），再进一步分析。在这里我走了很多弯路，一直觉得是SQL写的有问题，测试了很多次，发现修改一下条件该SQL就可以正常运行，但这只是我的猜测。另外我从ASH中发现了比较关键的一点,如下图一中红框中的servie。
图一 ASH截图
图二 SQL文本
2、这个时候又回到了最开始的问题ORA-07445，确定了SQL写法没有问题，但执行的时候就是报错。猜测是不是收集统计信息导致的，查看统计信息窗口，如下图三，不排除是收集统计信息导致的。
图三 统计信息窗口
4、根据该报错在MOS上查找相应文章，果真找到了比较相似的报错，如下图四
图四 MOS截图
5、根据MOS的解决方法
（1） Gather statistics after setting the below parameter，调整隐含参数
alter session set "_optimizer_cost_based_transformation" = 'OFF';
（2）删除相关表统计信息后重新手工收集统计信息。
6、综合考虑，不调整参数，删除该表统计信息后重新收集。
（1）删除统计信息 exec dbms_stats.delete_table_stats('COREREAD','TEMP1'); （2）重新收集统计信息 exec dbms_stats.gather_table_stats(ownname => 'COREREAD',tabname => 'TEMP1',estimate_percent => 100,method_opt=> 'for all columns size skewonly',cascade=>TRUE) |
7、再次测试删除统计信息并手工收集后，SQl可以正常执行了。该问题定位为Bug.
