cursor: pin S wait on X 等待事件

Inkcup

cursor: pin S wait on X 等待事件：
本质是SQL解析或执行过程中，由于共享游标（Shared Cursor）上的并发访问冲突而产生的等待。

等待事件的原理：
===========
这个等待事件直接关联到Oracle的Mutex（互斥锁）机制，这是Oracle从10g开始引入，用来替代Library Cache Pin，以更高效地管理共享内存中的游标（Cursor）的。

具体到这个等待事件，典型的场景是：

-会话A 正在对某个SQL进行硬解析（Hard Parse），为了构建新的执行计划，它以独占（X）模式持有该游标相关的Mutex。

-会话B 恰好在同一时间也想执行同一个SQL，它需要以共享（S）模式获取同一个游标，以便进行软解析并执行。

-因为会话A还“霸占”着资源，会话B无法立刻获得共享访问权，于是就产生了 cursor: pin S wait on X 的等待。

什么情况会导致大量等待？
=================
这个等待事件常常是更深层次问题的信号，而不是问题本身。导致它大量出现的原因通常有以下几个：

1.极高频的SQL执行：当某条SQL被极其频繁地执行时，即使都是高效的软解析，也会因为频繁修改Mutex的引用计数而产生激烈竞争，导致等待。这是最常见的原因之一。

2.高版本数（High Version Count）：一个SQL因为各种原因（如绑定变量窥探、环境设置不同等）产生了大量的子游标（Child Cursor）。当需要查找或维护这些子游标时，会造成Mutex被长时间持有，加剧等待。一个SQL的 VERSION_COUNT 如果超过20就值得关注了。

3.频繁的硬解析（Hard Parse）：如果应用没有使用绑定变量，导致SQL文本各不相同，就会产生大量的硬解析。硬解析本身需要以独占模式持有Mutex，会直接导致竞争。

4.已知的软件BUG：某些特定版本（如Oracle 12.1.0.2）中，存在与ILM（信息生命周期管理）特性相关的代码路径问题，会在创建子游标时引入不必要的延迟，触发大量等待。这种情况通常需要应用特定的补丁来解决。

如何分析与解决？
--------------
根据原理和常见原因，可以按以下步骤来排查和处理：

1.定位“热”SQL：首要任务是找到引发争用的SQL语句。通过 P1 参数（idn，即 hash_value）可以在AWR/ASH报告或v$session中定位到具体的SQL_ID。

2.分析根源：

        检查该SQL的执行频率是否异常高。

        在v$sqlarea中查看它的VERSION_COUNT，如果这个值很高（比如数百或数千），说明存在子游标过多的问题。

        检查应用代码是否使用了绑定变量。

3.采取行动：

        治理“热”SQL：如果是一条超高频率的简单查询，可以通过在SQL中添加不同的注释（Hint）来将其拆分为多条略有不同的SQL，从而将竞争分散到不同的游标上。

        降低版本数（High Version Count）：诊断并消除导致高版本数的根本原因，例如统一会话的NLS设置、优化器参数等。在极端情况下，可以使用DBMS_SHARED_POOL.PURGE清理有问题的游标。

        检查补丁：确认数据库版本，并在MOS（My Oracle Support）上查询是否有针对此问题的已知BUG和对应补丁。

值得注意的一点是，即使通过正确的优化，这个等待事件也很难完全消除。我们优化的目标是将其控制在一个可接受的范围内，使其不再成为性能瓶颈。