ITPub博客

首页 > 数据库 > Oracle > 记一次由11gr2的新特性引起的ora-4031

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

原创 Oracle 作者:liujl_ 时间:2015-12-17 07:40:41 0 删除 编辑


--写的不好,请各位看官多多包涵!


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






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



 


这是我摘取的09001000和前一天的历史会话信息由于我没有截全,所以可能这里看不大出来,是事实上都是cursorpin






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



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

请登录后发表评论 登录
全部评论

注册时间:2014-12-17

  • 博文量
    39
  • 访问量
    35937