'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'型別的等待事件

mosdoc發表於2016-12-04
Mutex型別事件

文件內容

用途
問題和答案
  什麼是 '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.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/17086096/viewspace-2123169/，如需轉載，請註明出處，否則將追究法律責任。

相關文章