运用系统分析方法解决 11g第一个bug-CSDN博客

一分公司应用系统出问题
不少错误
ORA-00600: 内部错误代码, 参数: [19004], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbz_find_bpid_3], [7], [], [], [], [], [], []
搜索metalink没有找到相关信息,找oracle咨询一下也暂时没有答案.
时间很紧,远水解不近渴.决定自己动手解决问题.
提取发生sql看到底有什么规律,发现sql都是多表join,并较复杂.只集中在几个表.
在测试环境测试,这些sql,并不会发生问题
测试环境与实际的环境有什么不同?
结合11g的自动分析表的功能,最大不同在于shared pool,也就说问题很有可能发生执行计划解析过程.

如此制订测试方案:
测试分为如下:
1.(想起10g曾碰到的bug类似,虽然oracle称在11g解决)
对测试环境使用同样统计信息收集看问题是否重现.结果问题没法重现.而且其他很多表连接,也没有问题.
--说明与10g ora-600 19004不一样
2.改变sql写法,用两条sql取代多表join,同时减少sql复杂.结果果然没有问题
3.使用hint /*+ rule */避开使用CBO执行计划,结果没有问题但性能差.

到这问题大致确定范围,应是11g bug发生到执行计划解析过程.发生可能环境:
1.sql都是多表join,并较复杂.
2.使用CBO
解决:改变sql写法,但要改变应用程序.
进一步分析:是否可以删除统计信息解决问题让优化器使用RBO.这样就不用做任何改变.
exec dbms_stats.delete_table_stats('owner','table_name');
结果没有问题但性能差
----这样问题基本解决,系统继续正常运行
随后时间,聚焦统计信息收集.作为老DBA,自然想起老朋友 analyze.
通过多次测试
analyze table .. estimate statistics sample 5 percent;
就能解决这个问题了.执行计划也不错
最后使用11g lock statistics 加以锁定.
问题解决后的思考:
1.运用系统分析方法,去分析问题,不应囿于DBA;将使分析能力,视野大大扩展.
2.11g的自动分析表的功能,要小心使用
3.CBO虽然强大,但问题不少.避免写相当复杂,而又不优化的sql.可用pl/sql or 一段程序来替代.尤其在OLTP上.