暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

cursor: pin S wait on X等待和high version count

原创 陈龙 2019-03-22
1027

问题描述

load profile的信息:

image.png

看着除了硬解析比例稍微高点,会话登录有点频繁,并没有什么大问题。

image.png

Library Hit命中率比较低

继续看比较关键的等待事件

image.png

请帮忙分析下原因?

专家解答

从图上cursor: pin S wait on X等待次数超多,且占比最高,接近90%。这个等待事件的意思是有会话试图以共享模式获取mutiex pin,但其他会话以独占方式持有游标对象的mutex pin,于是造成该等待。而产生该等待的主要原因,有以下几种:

l   shared pool设置不合理

l   硬解析过多

l   大量的version count

l   bug

l   解析失败

在AWR中检查SQLStatistics部分,在version count类里,发现明显异常

image.png

其他语句也类似,中间都有类似":SYS_B_X"字样,看起来是不是很像绑定变量?确实是,但一般应用的绑定变量都是类似":B1"之类,这个却明显不一样。设置过cursor_sharing参数的同学应该知道,这是数据库自己生成的绑定变量,继续检查初始化参数.

image.png

首先,cursor_sharing这个参数对系统性能和稳定性都非常重要,可惜经常被忽略,建议使用该参数的默认值:

    即 cursor_sharing=EXACT  (而不是FORCE或similar)

    这要求应该使用绑定变量的地方,必须使用绑定变量。这个对于OLTP系统来说是铁律,不容置疑,cursor_sharing=FORCE通常就是为了解决该使用绑定变量而没有使用绑定变量的情况。

其次,还有一个重要的内容:

不该使用绑定变量的地方,不用绑定变量:对那些唯一值较少的字段,特别是数据分布不均的情况,不建议使用绑定变量,这种情况如果使用了绑定变量,就是绑定变量窥视和ACS发挥作用的时候。

如果cursor_sharing=FORCE;或者cursor_sharing=EXACT,但是在数据分布不均的字段上也使用了绑定变量(两者基本上是等同的,虽然后一种略好于前一种情况),那么就要考虑“绑定变量窥视”和“自适应游标”两个参数的影响了。

最后修改时间:2019-04-14 10:48:42
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论