适用于:

用途

本文章针对与CURSOR(游标)管理活动相关的等待事件提供了一些核心要点信息。

问题和答案

什么是 'cursor: ' 等待事件？

处理或访问cursor的任何操作都可能需要等待，才能访问在 shared pool 中支持这些操作的结构。在极限争用的情况下，这些等待事件就会成为一个显著瓶颈，继而束缚正常活动。从版本 10.2 开始，一些共享cursor操作开始由 Oracle 的 Mutex 功能实施，在 11g 中 Librarycache 和 rowcache 组件也通过 Mutex 实施。

最常见的等待事件是什么？

最常见的等待事件包括：

• cursor: mutex X
• cursor: mutex S
• cursor: pin X
• cursor: pin S
• cursor: pin S wait on X
• library cache: mutex X
• library cache: mutex S

等待事件最常见的原因是什么？

基于这些事件的争用通常是另一个问题的症状表现 – 即问题是其它地方产生的，而不是 mutex 机制本身。如果需要解决 mutex 竞争这个问题表现，我们需要识别问题根本原因并加以处理。

Cursor 相关等待事件是 SQL 语句在 parse 时产生的，包括将cursor加载到 shared pool 中或在其中搜索那些cursor。出现这些问题可能的原因：

• shared pool 中 cursor 的版本数变得过多
• 过多的硬/软分析
• 过多的无效/重新加载
• 加载了大量的对象
• shared pool 大小不合适
• 资源的持有者被 OS 或者 Resource Manager 从 CPU 上移除
• 内存的操作系统管理（例如 Linux x86-64 上非常大的 SGA，而没有实施 Hugepage）
• 代码缺陷

如果 cursor 共享的很好，并且 child cursor 和版本数量较低，那么一般不会产生这种类型的争用。

如何避免这些等待事件？

通常，通过采用合理的cursor共享策略，正确使用绑定变量并确保没有大量版本，应该能够避免大多数这类性质的问题。有用的文章包括：

如果您发现自己有大量 cursor 版本，参阅以下文章可能会有所帮助：

可以在什么位置找到原因诊断以及关于这些等待事件的更多信息？

• • 常见诊断
    
    因为这些等待事件具有相似的原因，因此有些诊断信息对所有的等待都适用：
    
    • 问题的历史记录
      因为这些等待事件具有相似的原因，因此有些诊断信息对所有的等待都适用：
      
      • 最近更改了什么？
        
        • 应用程序、数据库、中间件层更改
        • OS 更改
        • 负载的增加
      • 共性或因果关系
        
        • 是否有任何特定事件看起来会触发问题？
        • 问题是否总在特定时间段发生？
    • 诊断依据
      通常需要进行大量诊断才能确定问题。这是因为这类等待事件是一种症状表现，阻塞会话可能与等待会话没有任何关系，只是它碰巧将后者阻塞而已。
      
      • AWR（或 Statspack）和 ASH 报表（用于等待会话）
        这些提供了系统概览并且还根据需要关注了单个会话
      • Stack trace(s) 堆栈跟踪
        通过 stack trace 我们可以看到资源持有者正在处理的代码区域。
        
        • 如果无法找到资源持有者：收集包含 short stack dump 的Systemstate dump
          （收集关于每个会话的信息应该可以捕获到持有者）
        • 如果无法标识持有者：收集等待者的 Errorstack
      • 操作系统统计信息（例如 OSWatcher）
        操作系统统计信息非常有用的原因有多种，如标识高 CPU 用户、找出活动的高峰，以及标识“构建”符号来帮助触发早期的数据捕获。
      请注意，在具有大量会话的忙碌系统上获取 systemstate 可能需要很大开销。
      如果是这种情况，则可考虑生成不同的 dump ，但是这些 dump 提供的信息会减少，可能不足以进一步诊断问题。所以，按照最有用（且最大开销）的信息从高到低排序，请尝试获取：
      
      
      • 级别 266 的 Systemstate（包含堆栈的 Systemstate）
      • 级别 258 的 Systemstate（包含堆栈不太详细的 Systemstate）
      • 具有堆栈跟踪的 Hanganalyze 输出
      
      例如，如果级别 266 systemstate 开销太大，则您可以尝试使用级别 258。您还可以合并上述各项。例如，获取一个级别 266 systemstate 和多个 hanganalyze dump。（hanganalyze dump应该包括 short stack dump）。
    • 数据收集参考资料：
      
      Note:1363422.1 AWR Reports - Information Center 
      Note:748642.1 How to Generate an AWR Report and Create Baselines [ID 748642.1]
      
      Note:1364257.1 How to Collect Errorstacks for use in Diagnosing Performance Issues.
      Note:452358.1 Database Hangs: What to collect for support.
      Note:175006.1 Steps to generate HANGANALYZE trace files.
      
      Note:301137.1 OS Watcher User Guide
      
      Note:1360119.1 FAQ: Database Performance Frequently Asked Questions

• • cursor: mutex X
    
    一个 cursor 正在被parse 并尝试以 eXclusive 模式获取 cursor mutex

• • cursor: mutex S
    
    一个 cursor 正在被parse并尝试以 Share 模式获取 cursor mutex
    
    
    Note:9591812.8 Bug 9591812 - Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X")

• • cursor: pin X
    
    一个 cursor 正在被parse 并尝试以 eXclusive 模式获取cursor pin

• • cursor: pin S
    
    一个 cursor 正在被parse并尝试以 Share 模式获取cursor pin。请参阅：
    
    
    Note:1310764.1 WAITEVENT: "cursor: pin S" Reference Note
    
    如果在此事件中发现争用，最好查找其他相关等待事件并首先对其进行调查，因为这个等待很有可能只是其它争用的症状。

• • cursor: pin S wait on X
    
    一个 cursor 正在被parse 并持有了 cursor pin，而且尝试在 eXclusive 模式下获取该 cursor pin。如果在 AWR的“Top Waits”部分看见 'cursor: pin S wait on X' 突出显示，如下所示：
    
    
    
    则应该首先查看您在系统中具有的 cursor 版本数：
    
    
    
    如果它们接近此处显示的异常高的数量，则根据优先级减少 cursor 版本。请参阅：
    
    
    Document 296377.1 Troubleshooting: High Version Count Issues
    
    如果不是这个原因导致的，您可以使用下列文章帮助排除问题：
    
    
    Note:1349387.1 Troubleshooting 'cursor: pin S wait on X' waits
    Note:1298015.1 WAITEVENT: "cursor: pin S wait on X" Reference Note
    Note:786507.1 How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' 
    
    Note:742599.1 High 'cursor: pin S wait on X' and/or 'library cache lock' Waits Generated by Frequent Shared Pool/Buffer Cache Resize Activity
    
    Note:1268724.1 "Cursor: Pin S Wait On X" Contention Mutex Sleep Reason Primarily ' kkslce [KKSCHLPIN2]'
    Note:402027.1 Bug:5653007; 5485914: SELF DEADLOCK PROCESS WAITS ON ''Cursor: Pin S Wait On X'' with SQL_TRACE enabled.
    Note:9472669.8 Bug 9472669 - 'cursor: pin S wait on X' waits for invalid SQL over DB link

• library cache: mutex X
  
  此处将执行 library cache 操作并尝试在 eXclusive 模式下获取 library cache mutex。
  
  "library cache:mutex X" 症状非常常见，很多问题都会导致该症状，所以完全理解根本原因以便确定正确的操作是非常重要的。在大多情况中，可以通过对应用程序进行更改（例如阻止登录或注销风暴）来减轻问题。还有可能是遇到了已知 Oracle bug（这包括与互斥相关的问题，以及具有互斥等待事件症状的非互斥问题）。
  
  
  Note:1357946.1 Troubleshooting 'library cache: mutex X' waits.
  
  Note:727400.1 WAITEVENT: "library cache: mutex X"
  Note:758674.1 " Library Cache: Mutex X " On Koka Cursors (LOBs) Non-Shared :
  Note:9530750.8 Bug 9530750 - High waits for 'library cache: mutex X' for cursor Build lock

• library cache: mutex S
  
  此处将执行 library cache 操作并尝试在 Share 模式下获取 library cache mutex

有用参考

参考