关于cursor: pin S wait on X

[复制链接]
查看11 | 回复9 | 2010-10-8 09:28:51 | 显示全部楼层 |阅读模式
cursor: pin S wait on X
A session waits for this event when it is requesting a shared mutex pin and another session is holding an exclusive mutex pin on the same cursor object.
从cursor: pin S wait on X的定义里面可以知道,当另外一个session以排它的方式持有pin时,其他对象才不能共享,那么应该是使用了alter 等之类的语句,但是为什么我的数据库里
select *from acc_pay_take_rule t where t.active_datesysdate
你以上这种语句都会等待在这个事件上,而且同一时间内并没有类型的SQL,对该表进行操作!
谁能给我介绍一下咯!谢谢!~~
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
自己顶一下,大家帮忙解释一下咯
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
你可以看p1得出什么sql block住了。
wait on x的是指cursor要被exclusive模式占用,比如flush shared pool操作,ddl on object操作。。。
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
通过P2RAW看看是谁是blocker。
如果一个session正在解析这个cursor,而另一个session要执行,那么就会产生此事件
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
恩,hard parses过多,shared pool resize等都会造成这个事件
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
还是不明白,为什么我通过p1的值(通过v$sql的hash_value)查出,阻塞的sql与等待在该事件上的sql是一致的,都是select 语句?
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
p1就是你的被block的cursor,要查阻塞者:
P2 Mutex value (top 2 bytes contains SID holding mutex in exclusive mode, and bottom two bytes usually hold the value 0)
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
http://warehouse.itpub.net/post/777/493962
以前做的一点总结,可以参考一下
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
p1是被阻塞的 当然一样你要查阻塞者
回复

使用道具 举报

千问 | 2010-10-8 09:28:51 | 显示全部楼层
hehe
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行