说明:
数据库由11.1.0.6升级到11.2.0.2后不时出现系统整体性能急剧下降,查看系统系统顶级活动,发现因某条SQL语句并发度极高几乎占用所有的CPU资源,删除该语句执行计划系统恢复正常。原先以为执行计划选择不正确,调整系统收集样本量,创建执行计划基线,最后无效。
通过STATSPACK发现cursor: mutex S、library cache lock值在此时高得异常,在网上搜索了有关于这cursor:mutex S造成CPU资源占用异常的案例,但貌似均未有比较全面的解决办法。
也一直苦于没有METALINK支持,很多相关的文件资料无法查阅。问题因此一直拖着未解决。以下是由获得资料后形成的解决办法。
分析及解决:
以上说明有两个问题,一是CPU资源使用异常,二是cursor: mutex S、library cache lock值在此时高得异常。
通过查阅,发现问题一是由于
Bug 6904068 High CPU usage when there are "cursor: pin S" waits
引起。此BUG在2011年5月份前就可以通过相应版本PSU解决此问题。由于我是在下半年才打PSU直接打了12827731: GI PSU 11.2.0.2.4(PSU)。CPU资源使用问题得到解决。
但是,打完补丁后,发现cursor: mutex S、library cache lock事件仍再次出现。通过AWR发现部分SQL语句版本极高。查看原因,是由于PX_MISMATCH造成。同时,因为系统开发时未考虑游标共享,直接通过CURSOR_SHARING为SIMILAR实现游标共享。向官方提交SR,经过跟踪相应SQL语句,未发现异常情况后,建议将CURSOR_SHARING设置为FORCE,同时要求开发时要求实现变量绑定。调整后,系统到目前为止尚未再出现。
后记:两个问题,拖了近一年,困扰了近一年,最终解决也只不过几行字而已,感慨ORACLE卖得不是数据库,而是PATCH,是DOCUMENTS。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22890736/viewspace-715922/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22890736/viewspace-715922/