常见问题：‘cursor:mutex ..‘/ ‘cursor:pin ..‘/ ‘library cache:mutex ..‘类型的等待事件

常见问题：'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'类型的等待事件 (Doc ID 1525791.1)

​编辑To Bottom

---

文档内容 用途 问题和答案 什么是 'cursor: ' 等待事件？ 最常见的等待事件是什么？ 等待事件最常见的原因是什么？ 如何避免这些等待事件？ 可以在什么位置找到原因诊断以及关于这些等待事件的更多信息？ 有用参考 参考 适用于: Oracle Database - Enterprise Edition - 版本 10.1.0.2 和更高版本 Oracle Database - Standard Edition - 版本 10.1.0.2 和更高版本 Oracle Database - Personal Edition - 版本 10.1.0.2 和更高版本 Oracle Database Cloud Schema Service - 版本 N/A 和更高版本 Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - 版本 N/A 和更高版本 本文档所含信息适用于所有平台 用途 本文章针对与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 请注意，所有这些等待事件都非常相似，并且可能都是在一个操作过程中产生的等待。eXclusive(排他)操作是需要更改特定结构的那些操作；Share(共享)操作可以在不更改的情况下进行，只是需要在更改过程中暂时锁定这些操作，以防止其被其他项更改。这点区别实际对于问题的诊断并没有太多关联，只是特定等待事件可能在特定问题中更为常见。 等待事件最常见的原因是什么？ 基于这些事件的争用通常是另一个问题的症状表现 – 即问题是其它地方产生的，而不是 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共享策略，正确使用绑定变量并确保没有大量版本，应该能够避免大多数这类性质的问题。有用的文章包括： Note:62143.1 Understanding and Tuning the Shared Pool Note:94036.1 Init.ora Parameter "CURSOR_SHARING" Reference Note 如果您发现自己有大量 cursor 版本，参阅以下文章可能会有所帮助： Note:296377.1 Troubleshooting: High Version Count Issues Note:438755.1 Formated V$SQL_SHARED_CURSOR Report by SQLID or Hash Value 可以在什么位置找到原因诊断以及关于这些等待事件的更多信息？ 常见诊断 因为这些等待事件具有相似的原因，因此有些诊断信息对所有的等待都适用： 问题的历史记录 因为这些等待事件具有相似的原因，因此有些诊断信息对所有的等待都适用： 最近更改了什么？ 应用程序、数据库、中间件层更改 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 有用参考 Note:34579.1 WAITEVENT: "library cache pin" Reference Note 参考 NOTE:9530750.8 - Bug 9530750 - High waits for 'library cache: mutex X' for cursor Build lock NOTE:1360119.1 - * FAQ: Database Performance Frequently Asked Questions NOTE:1363422.1 - Automatic Workload Repository (AWR) Reports - Main Information Sources NOTE:402027.1 - Bug:5653007; 5485914: SELF DEADLOCK PROCESS WAITS ON ''Cursor: Pin S Wait On X'' with SQL_TRACE enabled. BUG:5653007 - SELF DEADLOCK PROCESS WAITS ON ''CURSOR: PIN S WAIT ON X'' NOTE:1364257.1 - How to Collect Errorstacks for use in Diagnosing Performance Issues. NOTE:1357946.1 - Troubleshooting 'library cache: mutex X' Waits. NOTE:1298015.1 - WAITEVENT: "cursor: pin S wait on X" Reference Note BUG:9591812 - INCORRECT WAIT EVENTS IN 11.2 NOTE:1268724.1 - "Cursor: Pin S Wait On X" Contention Mutex Sleep Reason Primarily ' kkslce [KKSCHLPIN2]' NOTE:786507.1 - How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' NOTE:9472669.8 - Bug 9472669 - 'cursor: pin S wait on X' waits for invalid SQL over DB link NOTE:727400.1 - WAITEVENT: "library cache: mutex X" NOTE:742599.1 - High 'Cursor: Pin S Wait On X', 'Library Cache Lock' And "Latch: Shared Pool" Waits due to Shared Pool/Buffer Cache Resize Activity NOTE:94036.1 - Init.ora Parameter "CURSOR_SHARING" Reference Note NOTE:9591812.8 - Bug 9591812 - Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X") NOTE:34579.1 - WAITEVENT: "library cache pin" Reference Note NOTE:748642.1 - How to Generate an AWR Report and Create Baselines NOTE:62143.1 - Troubleshooting: Understanding and Tuning the Shared Pool NOTE:361468.1 - HugePages on Oracle Linux 64-bit NOTE:1310764.1 - WAITEVENT: "cursor: pin S" Reference Note NOTE:1349387.1 - Troubleshooting 'cursor: pin S wait on X' waits. NOTE:758674.1 - " Library Cache: Mutex X " On Koka Cursors (LOBs) Non-Shared : NOTE:296377.1 - Troubleshooting: High Version Count Issues NOTE:301137.1 - OSWatcher (Includes: [Video]) NOTE:438755.1 - High SQL Version Counts - Script to determine reason(s) NOTE:452358.1 - How to Collect Diagnostics for Database Hanging Issues NOTE:175006.1 - Steps to generate HANGANALYZE trace files (9i and below)