记一次由11gr2的新特性引起的ora-4031

--写的不好，请各位看官多多包涵！

11月份的某一天中午，正准备去吃午饭同事接到应用那边电话，才迁移不到一个月的应用系统后台报了ora-4031错误，同事当机立断加了2G的shared_pool(女汉子办事就是直接)先恢复业务再说。由于当时是我做的迁移这套库的环境还是比较熟悉的，这套库先前未做迁移前其实一直的状态是cpu使用率100% ,wio 20%+，倒不是我们不想处理只是各种原因（应用不愿整改就想换个新机器），迁移完成没过两天发现还是老状态cpu 100%。最后没办法还是自己去整改了。综合上诉因素，所以决定上去探个究竟。关于ora-4031错误其实分析很简单，基本上可以分为两大类:第一类，子curosr不共享。第二类，父游标不相同。拉了一份awr报告一眼可以看出问题大量的cursor:pin s wait on x 于是乎去关注一下curosr的version_count 发现除了第一条的oracle自身的语句version count有320其他看上去都还可以，不算多，好吧这样的version count数量是不能代表什么问题。

那就登上系统看一下历史活动会话，到底数据库是处在一个什么样的状态首先我看了11：00到11：30，排除因政治原因没处理的其他异常等待全是cursor，最重要的是我发现其实这些sql_id都是不同。

 

这是我摘取的09：00到10：00和前一天的历史会话信息由于我没有截全，所以可能这里看不大出来，是事实上都是cursor：pin。

那么现在其实已经可以做判断了4031错误不是应用那边sql写法问题像我们常说的绑定变量和大量的动态sql导致的大量硬解析。原因是child cursor不共享，于是我把上面的大部分sql_id拉了出来通过v$sql_shared_cursor看一下是什么原因造成不共享的，这过程我发现其实每一条的sql_id对应的cursor version并不多就10多个或者几个。因为该系统迁移过来也才不到一个月，所以这其实已经值得我们关注了。看了差不多10几个我发现每一条不共享的原因都是用了Cardinality Feedback。Cardinality Feedback（基数反馈）是版本11.2中引入的的新特性，针对统计信息陈旧、无直方图或虽然有直方图但Cardinality依旧计算不准确的情况，造成CBO选择不当的执行计划，而引入Cardinality Feedback特性。但是就是由于这个新特性导致大量的游标不共享，所以当机立断把这个新特性禁用了，由于是业务高峰期所以没有flush shared_pool。第二天我摘取了同一时段的awr，效果立竿见影。这套系统的后续优化有机会的话我会分享出来。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30068249/viewspace-1873664/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30068249/viewspace-1873664/