0

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

陈龙 2019-03-22
97
摘要:loadprofile的信息:看着除了硬解析比例稍微高点,会话登录有点频繁,并没有什么大问题。LibraryHit命中率比较低继续看比较关...

问题描述

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,但是在数据分布不均的字段上也使用了绑定变量(两者基本上是等同的,虽然后一种略好于前一种情况),那么就要考虑“绑定变量窥视”和“自适应游标”两个参数的影响了。

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部
暂无课程,敬请期待...