【MOS】常见问题cursor library cache类型的等待事件



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



文档内容

用途
问题和答案
  什么是 '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 和更高版本
本文档所含信息适用于所有平台

用途

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

问题和答案

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

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

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

最常见的等待事件包括：

请注意，所有这些等待事件都非常相似，并且可能都是在一个操作过程中产生的等待。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:1298015.1 - WAITEVENT: "cursor: pin S wait on X" Reference Note

BUG:9591812 - INCORRECT WAIT EVENTS IN 11.2 ("CURSOR: MUTEX S" INSTEAD OF "CURSOR: MUTEX X")

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:94036.1 - Init.ora Parameter "CURSOR_SHARING" Reference Note
NOTE:758674.1 - " Library Cache: Mutex X " On Koka Cursors (LOBs) Non-Shared :
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' and/or 'library cache lock' Waits. Cause: Shared Pool/Buffer Cache Resize Activity
NOTE:175006.1 - Steps to generate HANGANALYZE trace files (9i and below)
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:9530750.8 - Bug 9530750 - High waits for 'library cache: mutex X' for cursor Build lock
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: Tuning the Shared Pool and Tuning Library Cache Latch Contention
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:1357946.1 - Troubleshooting 'library cache: mutex X' waits.
NOTE:1360119.1 - * FAQ: Database Performance Frequently Asked Questions
NOTE:1363422.1 - Automatic Workload Repository (AWR) Reports - Start Point
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.

时间： 2024-10-24 17:04:23

【MOS】常见问题cursor library cache类型的等待事件的相关文章

[20170727]library cache: mutex X.txt

[20170727]library cache: mutex X.txt --//如果多个会话访问v$sql视图,其底层视图是x$kglcursor_child,如果几个会话同时访问,会出现library cache: mutex X等待事件,通 --//过例子说明: 1.环境: SYS@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ ---

Oracle中常见的33个等待事件小结

在Oracle 10g中的等待事件有872个,11g中等待事件1116个. 我们可以通过v$event_name 视图来查看等待事件的相关信息   一． 等待事件的相关知识 1.1 等待事件主要可以分为两类,即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件. 1). 空闲等待事件指ORACLE正等待某种工作,在诊断和优化数据库的时候,不用过多注意这部分事件. 2). 非空闲等待事件专门针对ORACLE的活动,指数据库任务或应用运行过程中发生的等待,这些等待事件 是在调整数据库的时候

Oracle 等待事件 一

以前一直想整理一下关于Oracle 的等待事件,总是没时间.现在觉得应该着手做了,其中的一些知识来自于自己的一点研究,如有错误,望大家指正..... 一 Oracle等待事件主要有两类事件: 1 空闲等待  空闲等待意味着Oracle正在等待某种动作的发生,实际上并不是因为繁忙而等待,而是因为没有事情做所以等待,如:smon timer,SMON进程的一些操作时每隔一段实际循环执行的,即使系统不忙,此事件也不立即发生,而是等待计时器达到一定的时间才执行,此时出现的smon timer 等待事件,

Oracle后台专家解决library cache锁争用的终极武器

  11月19日,云汝网络科技合伙人宋日杰(Roger Song)在"DBA+东北群"进行了一场关于"使用Hotcopy缓解 library cache: mutex X 的争用"的线上主题分享.小编特别整理出其中精华内容,供大家学习交流.    嘉宾简介    DBA+原创专家团成员 超过13年IT及Oracle数据库经验 历任中国联通系统工程师.维布络信息科技Oracle ERP管理顾问 2008年加入Oracle全球技术支持(GCS),专注性能分析 2012年

ORACLE11G QMNC引起的library cache: mutex X

   操作系统类型:Linux ### 2.6.39-400.17.1.el6uek.x86_64 #1 SMP Fri Feb 22 18:16:18 PST 2013 x86_64 x86_64 x86_64 GNU/Linux       数据库版本:SQL*Plus: Release 11.2.0.4.0 Production    数据库类型:OLAP    问题现象描述:最近通过linux的top发现有2个进程始终占用CPU90%左右,如下图所示:          然后查看相关进程

oracle等待事件5——库高速缓存上的等待事件 中

3.library cache lock 和 library cache pin library cache lock 的定义:访问或修改库高速缓冲区的对象时,对库高速缓冲区句柄(handle)获得的锁,在获得library cache lock 的过程中,如果发生争用,则等待library cache lock事件. 通过library cache lock 事件的P1=handle address  P2=lock address  P3=mode*100+namespace,可以掌握对哪个

Oracle OWI 等待事件历史视图及相关视图

    Oracle提供的等待事件视图使得我们可以获取指定session以及实例级别等待事件的详细信息,这些视图分别是v$session_wait,v$session_event,以及v$system_event.然而这几个视图对于历史等待事件无能为力.对此,Oracle也提供了历史等待事件视图v$session_wait_history,同时视图v$session_wait_class,v$system_wait_class也提供了基于等待类别的性能分析,下面是基于Oracle 10g对此展开

[20150326]关于等待事件的注意问题.txt

[20150326]关于等待事件的注意问题.txt --昨天重新看,书中提到等待事件的注意事项.oracle随着版本号加大,等待事件增加越来越多. --书中提到一般分为两类:一类是主动触发事件.另一类是被动触发事件,还提到了一个小的注意事项,实际上自己以前也遇到过,还是自己 --做一个小例子来说明: 1.建立测试环境: SCOTT@test> @ver1 PORT_STRING                    VERSION        BANNER ------------------

Oracle Mutex 等待事件

Oracle Mutex 等待事件之: cursor pin S pin S 等待事件说明,当一个会话(session)试图去更新一个共享的 Mutex Pin,同时已经有其他会话正在更新(updating)同一个 Shared Mutex Pin.注意,Pin S 的Mutex位于子游标上,是动态创建的,无法从等待事件中获得,但是可以在竞争出现的情况下,通过观察 x$mutex_sleep_history 来获得. 文档说明如下: Oracle Mutex 等待事件之: cursor pin