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

文件內容

適用於:

用途

本文章針對與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

有用參考

參考