合 【MOS】故障排除“cursor: pin S wait on X”等待事件 (Doc ID 2901617.1)

故障排除“cursor: pin S wait on X”等待事件 (Doc ID 2901617.1)

Troubleshooting 'cursor: pin S wait on X' waits. (Doc ID 1349387.1)

排错步骤

什么是“cursor: pin S wait on X”等待事件？

游标等待与某种形式的解析相关联。 当会话尝试在共享模式下获取 mutex pin 资源，但另一个会话在同一个游标对象上以独占方式持有该 mutex pin 资源时，就可能会发生此等待事件。通常，等待“cursor: pin S wait on X”等待是一种症状，而不是原因。 可能存在潜在的调优要求或是遭遇了已知问题。

是什么引发“cursor: pin S wait on X”等待呢？

• 首先，要保证 shared pool 的大小设置正确。

  一般来说，如果 shared pool 大小不足或者承受负载的能力不足，就可能表现为“cursor: pin S wait on X”等待。如果使用了自动内存管理模式，那么这通常不是问题，详见：

  Document 443746.1 Automatic Memory Management (AMM) on 11g

• 频繁硬解析
  如果硬解析的频率很高的话，在 mutex pin 上就会发生竞争。

• 子游标版本数过高
  当子游标版本数过高时，需要检查一长串版本，这可能会导致对该事件的争用。

• 已知的 BUG

• 解析错误，详见以下文档：

  Document 1353015.1 How to Identify Hard Parse Failures

如何诊断原因

获取诊断信息用以帮助定位原因。

1. 比较“Cursor: pin S wait on X”等待期间和正常（基准）情况的 AWR 和 ADDM 报告。基准向我们展示了在问题和正常期间发生的典型“背景”下并发和活动情况，并且可能有助于识别出（例如）子游标版本数过高的 SQL。
   建议半小时到一小时间隔运行 AWR 和 ADDM 来收集信息，收集信息命令如下所示：

2. 有时为了匹配已知问题需要获取 system state dump 信息。例如，如果 AWR 中没有明显的候选 SQL，则需在 system state dump 中捕获 mutex bin 资源持有进程或等待进程以专注于潜在问题的分析。当进程发生“cursor: pin S wait on X”等待时，取得 System State Dump：

3. Errorstack：获取进程信息的另一种方法是使用 Errorstack。假设可以识别一个阻塞源，可以获取 Errorstack，Errorstack 提供的信息与 System State 的信息大致相同，但 trace 量可以很大程度的减少。一旦找到阻塞源的 ospid，就可以生成一个 Errorstack：

尤其是通过 trace 中的 Stack 信息可用于匹配已知问题。

Systemstate 和 errorstack 有可能不是很易读，此时，需要提交 SR 来解析 trace 文件。

4. 运行 system state dump 并不总是可行的， 因此也可以参阅以下文档查找阻塞进程：

Document 786507.1 How to Determine the Blocking Session for Event: 'cursor: pin S wait on X'

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。