AWR报告分析之三：cursor: pin S 的原理与案例分析

作者： eygle | English 【转载时请标明 出处和作者信息】|【 恩墨学院 OCM培训传DBA成功之道】
链接： http://www.eygle.com/archives/2013/01/awr_cursor_pin_share_case.html

站内相关文章|Related Articles

使用DBMS_SWRF_INTERNAL清理导入数据库的AWR信息
AWR报告分析之二：ges inquiry response 过高
AWR报告分析之一：高 DB CPU 消耗的性能根源
如何禁用Oracle AWR自动采样功能
AWR报告分析-如何清理AWR的导入数据

在以下数据库的AWR报告中，可以看到超高的Cursor: Pin S等待，这是一个由于频繁执行SQL共享解析时产生的竞争。当一个会话尝试以共享模式（S - Share）来获得一个游标时，需要修改相应的Mutex结构的引用计数（reference count），或者增加该计数，或者减少。修改引用技术的原子操作很快（其实和Latch的获取释放类似），但是在频繁解析的情况下，仍然产生了竞争和等待，由此就产生了 cursor : pin S 的等待。

这通常是由于某些SQL以超高频繁的频率执行导致的，当然也可能与系统的CPU能力不足有关。

Mutex机制在Oracle 10g引入，用于替代Library cache pin操作，其性能更高，其原理为在每个Child Cursor上分配一个地址空间记录Mutex，当该Cursor被共享执行时，通过将该位进行加一处理来实现。虽然是指游标共享，但是更新Mutex结构的操作需要排他，当某一个SQL被频繁共享执行时，可能就会出现Pin S的等待。

每个Library Cache对象都有一个reference count （引用计数），用来表明有多少其他对象目前正保留一个对它的引用（reference).  对象A 想要引用对象B, A 就把B 的 reference count 加 1。 当A 结束了对B 的引用， A 就把 B 的reference count 减 1.   当没有任何对象再引用 B 时， B 的 reference count就减为0， B 就被清除（deallocated）, 内存就被释放。清除B的时候， 被B所用的对象的 reference count 也可能减小， 也可能使它们被清除。

最简单的解决方案是，将频繁执行的SQL分区拆解，分散竞争，如以下SQL通过注释将同一条SQL分解为2条，就分散了竞争：
    select /*SQL 1*/ a from t_a where id=?

    select /*SQL 2*/ a from t_a where id=?
这种做法在Ebay、Papal、支付宝等公司被广泛采用。

在官方文档上这样解释：

A session waits for "cursor: pin S" when it wants a specific mutex in S (share) mode on a specific cursor and there is no concurrent X holder but it could not acquire that mutex immediately. This may seem a little strange as one might question why there should be any form of wait to get a mutex which has no session holding it in an incompatible mode. The reason for the wait is that in order to acquire the mutex in S mode (or release it) the session has to increment (or decrement) the mutex reference count and this requires an exclusive atomic update to the mutex structure itself. If there are concurrent sessions trying to make such an update to the mutex then only one session can actually increment (or decrement) the reference count at a time. A wait on "cursor: pin S" thus occurs if a session cannot make that atomic change immediately due to other concurrent requests. Mutexes are local to the current instance in RAC environments.

以下是这个用户的AWR报告，Top 5事件：

可以看到在SQL解析部分，前3条SQL的执行频率非常高（采样为60分钟间隔），这些频繁的SQL执行是产生Pin S的源头：

这几条SQL的语句全文是：

select * from sw_PRODUCTS where ID=:ID

select * from sw_SERIES where ID=:ID

select f_sale_price from product_sale_price where f_product_id=:product_id and F_PRICE_BM='ECBJ'

典型的简单SQL反复执行，通过前面探讨的SQL改写方案将可以解决这里面临的Cursor: Pin S问题。

以下是整个AWR报告的全文，可供参考：

http://www.eygle.com/pdf/awrrpt_1_11577_11578.html

其他参考资源：

MOS：1310764.1 .