分享：RAC 環境中最常見的 5 個資料庫和/或例項效能問題 (文件 ID 1602076.1)

文件內容

適用於:

用途

本文旨在提供關於 RAC 環境中最常見的資料庫和/或例項效能問題的摘要以及可能的解決方案

請注意，問題 3（Mutexes 上的大量等待）和問題 5（高 CPU 和記憶體開銷）是一般性資料庫問題，並非特定於 RAC 的問題。不過，本文中討論這些問題是因為這些是最常見的問題之一，會在 RAC 環境中的某一個例項發生。

適用範圍

DBAs

詳細資訊

問題 1：大量塊丟失 (gc lost blocks, gc current/cr lost blocks)

症狀

解決方案

問題 2：大量 log file sync 等待

症狀

背景

使用者會話在提交或回退時，會話的重做資訊需要由 LGWR 重新整理到重做日誌檔案。使用者會話等待“log file sync”的同時，等待 LGWR 通知確認所有重做更改已安全存放在磁碟上。

示例：

WAIT #0: nam='log file sync' ela= 977744 buffer#=754 p2=0 p3=0 obj#=114927 tim=1212384670107387

引數：

  P1 = buffer#
  P2 = 未使用
  P3 = 未使用
  obj# = object_id

對這個 buffer（在重做日誌緩衝區）的所有更改必須重新整理到磁碟並確認寫入，以確保事務處理已提交，並且在例項關閉之前一直保持為已提交狀態。

“log file sync”等待的典型生命週期

1. 使用者會話釋出提交或回退操作，然後開始等待 log file sync。
2. LGWR 收集要寫入重做日誌檔案的重做資訊，釋出 IO 並將 BOC 入隊到 LMS  程式，然後通知 LMS 程式。
3. LGWR 等待將重做資訊重新整理到磁碟以及等待 SCN 被確認收到
4. 完成 IO 並從 LMS 收到 SCN 的確認資訊，表示寫入完成。LGWR 然後通知前臺程式繼續。
5. 前臺程式被喚醒，並且 log file sync 等待結束。

與 log file sync 相關的重要統計資訊和事件

redo write time - 從重做日誌緩衝區向當前重做日誌檔案寫入所用的總時間，以10毫秒為單位。
redo writes - LGWR 向重做日誌檔案寫入的總次數。“寫入重做塊數”除以此 統計資訊等於每次寫入的塊數。
log file parallel write - 完成 I/O 的用時。雖然重做記錄是並行寫入的，但在最後一個 I/O 寫入到磁碟上之前，並行寫入不會完成。
redo write broadcast ack time - 在提交時，除了日誌寫入等待時間之外，與廣播相關的總等待時間長度，以毫秒為單位。
user commits - 使用者提交的數量。在使用者提交事務時，必須將所生成的、反映對資料庫塊更改的重做寫入到磁碟。提交操作通常代表的是最接近使用者事務率的內容。
user rollbacks - 使用者手動釋出 ROLLBACK 語句的次數或者使用者事務處理出誤的次數。
Document 1064487.1 - Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) 中提供的指令碼可以用於蒐集診斷log file sync問題的有用資訊。

可能原因

解決方案

問題 3：Mutexes 上的長時間等待

Mutexes 是比閂鎖(latches)更為輕型且粒度更細的並行機制。獲取 Mutex 的目的是為了確保正確管理特定操作的並行執行，例如，如果一個會話正在更改記憶體中的資料結構，則其他會話等到獲取Mutex 後，才能進行類似的更改。下面是最常見的與 Mutex 相關的等待：

A. cursor: pin S wait on X
B. cursor: pin S
C. library cache: Mutex X

症狀 (A)

背景 (A)

會話等待此事件是在它嘗試獲取共享模式的 Mutex 鎖時，其他會話在相同遊標物件上以獨佔方式持有 Mutex 鎖。通常，等待“Cursor: pin S wait on X”是症狀而非原因。其中可能需要進行底層的最佳化或者是已知問題。


可能原因 (A)

解決方案 (A)

症狀 (B)

背景 (B)

會話在申請共享模式下特定遊標上的特定 Mutex 時，雖然沒有並行的排他持有者，但無法立即獲取 Mutex，這時會等待“cursor: pin S”。這看上去有些不合理，因為使用者可能會不理解為什麼在沒有排他模式持有者的情況下會存在這種等待。出現這種等待的原因是，為了在共享模式下獲取 Mutex（或釋放Mutex），會話必須增加（或減少）Mutex 引用計數，這需要對 Mutex 結構本身進行獨佔原子更新。如果有並行會話在嘗試對 Mutex 進行這樣的更新，則一次只有一個會話能夠實際增加（或減少）引用計數。如果由於其他並行請求使得某個會話無法立即進行這種原子更新，則會出現等待“cursor: pin S”。
在 RAC 環境中，Mutex 只作用於本地例項。

引數：
   P1 = idn 
   P2 = 值
   P3 = where（10.2 中為 where|sleeps）

 idn 是 Mutex 識別符號值，與正在等待以獲取 Mutex 的 SQL語句的 HASH_VALUE 相匹配。可以用以下格式的查詢找到使用對應 IDN 的 SQL 語句：

SELECT sql_id, sql_text, version_count 
FROM V$SQLAREA where HASH_VALUE=&IDN;

如果遊標顯示的 SQL_TEXT 格式為“table_x_x_x_x”，則這是特殊的內部遊標，有關將此類遊標對映到物件的詳細資訊，請參閱 Document 1298471.1。 

P1RAW 是採用十六進位制值的相同值，可用於在跟蹤檔案中搜尋與該 hash（雜湊）值匹配的 SQL。

可能原因 (B)

解決方案 (B)

症狀 (C)

背景 (C)

在以前的 Oracle 版本中，獲取 library cache Mutex 與獲取 library cache latches 的目的相似。在 10g 中，為 library cache 中的特定操作引入了 Mutex。從 11g 開始，Mutex 取代了 library cache latches。只要某個會話以獨佔模式持有 library cache mutex 並且其他會話需要等待釋放 Mutex，就會出現此等待事件。

單獨等待：
引數：
  P1 = "idn" = 唯一的Mutex識別符號 
  P2 = "value" = 持有Mutex的會話ID 
  P3 = "where" = 等待 Mutex 的程式碼中的位置（內部識別符號）

系統範圍等待：
在系統範圍級別，有兩個檢視可用於幫助診斷此等待：

GV$MUTEX_SLEEP（對於非 RAC 為 V$MUTEX_SLEEPS）
和 GV$MUTEX_SLEEP_HISTORY（對於非 RAC 為 V$MUTEX_SLEEP_HISTORY）

在例項啟動後，這些檢視在例項範圍內跟蹤 Mutex 的使用情況。由於這些檢視顯示了自啟動以來的總數，在出現問題時，您可以獲取短時間間隔內值的差異，因此這些資料是非常有意義的。瞭解這些資訊最簡單的方法是檢視 AWR 或 statspack 報告的“Mutex Sleep Summary”部分。

可能原因 (C)

解決方案 (C)

問題 4：高 enq: TX -row lock contention, enq: TX - index contention, enq: TX - ITL allocate entry 等待

A. enq: TX - Index Contention
B. enq: TX - ITL allocate entry waits
C. enq: TX - row lock contention

症狀 (A)

背景 (A)

如果事務在索引中插入行時需要等待其他事務正在操作的索引塊拆分結束，則 會話將等待事件“enq: TX - index contention”。

可能原因 (A)

解決方案 (A)

症狀 (B)

背景 (B)

會話希望鎖定塊中的一行但一個或多個其他會話鎖定了相同塊中的行，並且塊中沒有空閒的 ITL 槽時，該會話會等待“enq: TX - allocate ITL”。通常，Oracle 資料庫將動態新增另一個 ITL 槽。如果塊中沒有足夠的空閒空間來新增 ITL，則這可能無法實現。

可能原因 (B)

解決方案 (B)

症狀 (C)

背景(C)

會話等待由其他會話持有的行級別鎖定時，等待“enq: TX - row lock contention”。當某個使用者更新或刪除了行但尚未提交或回滾，而另一個會話希望更新或刪除相同行時，會出現這種情況。

解決方案 (C)

問題 5：高 CPU 和記憶體開銷

A. 高 CPU 佔用率
B. 高記憶體使用率

症狀 (A)

可能原因 (A)

解決方案 (A)

症狀 (B)

可能原因 (B)

可能解決方案 (B)