故障排除："WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! "

文件內容

適用於:

用途

本文件的目的是幫助排查原因"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! "

排錯步驟

什麼是 row cache enqueue 鎖（Row Cache Enqueue Lock）？

行快取（Row Cache）或資料字典快取（Data Dictionary Cache）是儲存資料字典資訊的共享池的記憶體區域。row cache 儲存資料時並不是以資料塊的形式，而是以行的形式。row cache enqueue 鎖是在資料字典行的鎖。此 enqueue 是關於特定資料字典物件的。這就是所謂的 enqueue 型別，可以在檢視 V$rowcache 中找到。

對於每個版本 row cache 型別的列表，請參閱：

"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 警告資訊是什麼意思？

當我們試圖獲得 row cache 鎖，這種等待事件將被使用。
當 row cache 衝突發生時，如果不能在一個預定的時間週期內得到 enqueue，將在 USER_DUMP_DEST 或 background_dump_dest 目錄下生成一個跟蹤檔案，這取決於是使用者還是後臺程式建立的跟蹤檔案。alert.log 通常會相應的更新警告訊息和跟蹤檔案的位置。
資料庫檢測到核心資源被持有太久並通知管理員，從而讓這種情況可以得到解決。這也可能伴隨著資料庫掛起或變慢。
alert.log 的訊息和生成的跟蹤檔案趨向於包含訊息：

如果不能立即獲取 rowcache entry 鎖，那麼進入一個迴圈，先釋放 row cache 物件閂鎖，等待（等待上述等待事件），重新獲得閂鎖，然後再次嘗試獲取 rowcache 鎖。在單例項模式，會重複 1000次直到程式報錯“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。在 RAC 環境會一直重複，直到不能獲得例項鎖或者被中斷。

Systemstate dump 可以提供一些有用的資訊診斷爭用的原因。

"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 可能的原因

SGA收縮（shrink）/調整大小的操作（resize）

如果 SGA 動態地改變大小，需要持有各種 latches 來避免其它程式同時操作，直到操作完成。如果調整大小需要一段時間，或者是經常發生，你會看到"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!"的發生。定位這種情況的方法是，有很多'SGA: allocation forcing component growth'等待事件，或 AWR 的 TOP 列表有類似等待,以及阻塞等待"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 的會話在等待'SGA: allocation forcing component growth'（或類似）。有一些可用的程式碼修復，請參閱：

row cache enqueue 型別

對於每一個 enqueue 型別，都有對應的一些操作會需要獲取這類 enqueue。佇列的型別,可能給出由於操作可能導致的問題的指示。一些常見的原因如下：

最可能的原因是新 extent 的分配。如果 extent 大小設定過小，那麼應用程式可能會不斷地要求新的 extent，這可能導致爭用。你有很小的 extent 尺寸，正在迅速增長的物件嗎？（透過查詢具有大量 extents 的物件可以定位它們）。檢查 insert/update 活動的 trace，查詢那些就有很多 extents 的物件。

檢查應用程式用到的 sequence 的 cache 的大小：

一個會話正在對一個使用者執行 GRANT，與此同時此使用者正在登入到資料庫中，此時可能會發生死鎖或導致"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 。

這很可能是 segment 的分配導致的。確定持有鎖的使用者正在做什麼並使用 errorstacks 進行診斷。

這可能是由於 rollback 段的分配導致的。正如 dc_segments，確定誰持有鎖並收集 errorstack 來進行診斷。請記住，在多節點系統（RAC）上，持有者可能在另一節點上，因此需要所有節點的 systemstate。

此 enqueue 關係到 AWR（Automatic Workload Repository）的控制權。任何操縱 AWR 資料庫的操作將持有它. 要分析這個問題,需要查詢是那些程式阻塞了它們。

  RAC 相關的 Bugs

我可以收集哪些資訊，以確定原因？

Systemstate dump

當問題發生時，錯誤會記入 alert.log，並自動產生一個 systemstate dump 檔案。

AWR，ADDM 和 ASH 報告

收集兩份 AWR 報告，一份有問題時間段的,另一個是沒有問題時間段的，因為這些可以幫助我們理解問題發生時資料庫的狀況 AWR，ADDM，ASH 報告，可以相互取長補短，從而更完整地理解整個問題。

取決於 AWR 快照生成的時間間隔，收集最小時間間隔的報告。預設的快照是一個小時的時間間隔。

鑑於分析 systemstate 是一件很複雜的事情，您可以建立一個服務請求，並上傳 alert.log，systemstate dump，以及問題發生前和問題發生時的 AWR 報告請 Oracle 技術支援來分析。

如何分析收集到的診斷資訊？

Systemstate dump

通常情況下， row cache enqueue 是一系列事件的一部分，阻塞了申請 row cache enqueue 的程式的程式很可能被另一個程式阻塞。Row cache enqueue 經常是問題的表象。

Systemstate dump 可以幫助查詢申請的是哪一個 row cache ，並可能有助於發現阻塞程式。

trace 的標題顯示下列內容：

• 等待 row cache enqueue 鎖的 Oracle 程式號（PID）（在這個案例，程式 77）。
• 正在申請的 row cache enqueue 的模式（請求：S）。

因此，在上述例子中，程式 77 是在請求以共享模式獲得 row cache（請求：S）。

Systemstate 包含資料庫中每一個程式的狀態資訊，因此可以在 systemstate 中查詢這個程式：

從上面我們看到，程式 77 請求共享模式獲得 row cache dc_users。
程式 77 處於等待狀態，意味著被其它程式阻塞，我們現在需要檢查 systemstate 判斷誰持有資源並阻塞了這個程式。

搜尋引用的物件，在這個例子中，是 object=0x1dc9a5d30。
這樣做完以後，我們發現，程式 218 正以獨佔模式持有這個物件：

獨佔模式的請求，將會一直阻塞共享模式的請求，直到該程式獨佔模式的請求被滿足並稍後釋放了這個資源。因此，這將阻止其他共享模式請求。請注意，這是請求獨佔而不是獨佔持有，所以這個請求也一定被阻塞了。檢視其他程式中，我們看到程式 164 在以共享模式（mode=s）持有這個物件。

因此，程式 164 以共享模式持有 row cache enqueue（mode= S），從而防止了程式 218 以獨佔模式獲得該 row cache enqueue。此外，我們看到，程式 164 在 ON CPU（systemstate 顯示最後一個等待是'SQL*Net message from client'，而不是等待'SQL*Net message from client'）。為了進一步診斷，技術支援需要檢查堆疊呼叫，以確定為什麼這個程式在 ON CPU 並持有該佇列這麼久（從開始已經等待了2539秒）。

在這個例子中，程式 18（MMON）等待以共享模式獲得型別為 dc_awr_control 的 row cache。

物件（object=39a79f090）的 row cache lock 被程式 269 以獨佔模式（mode=x）持有。程式在等待'SGA: allocation forcing component growth'。

因此根本原因就是 SGA 的大小調整，等待 row cache 是次要結果。
我們使用該期間的 AWR 報告看相關資訊：

AWR 報告

Top 5 Timed Events                                         Avg %Total               
~~~~~~~~~~~~~~~~~~                                        wait   Call               
Event                                 Waits    Time (s)   (ms)   Time Wait Class    
------------------------------ ------------ ----------- ------ ------ ----------    
SGA: allocation forcing compon   42,067,317      38,469      1    7.6      Other    
CPU time                                          2,796           0.6               
db file sequential read             132,906         929      7    0.2   User I/O    
latch free                        4,282,858         704      0    0.1      Other    
log file switch (checkpoint in          904         560    620    0.1 Configurat    
          -------------------------------------------------------------       

我們可以清楚地看到，在 Top 5 等待事件中，整個系統中有針對此事件的一個顯著等待；並且'SGA: allocation forcing component growth' 是這一時間點的一個主要問題。"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 訊息的根本原因就是記憶體調整活動，TOP 5 的等待事件甚至不顯示等待“row cache"症狀。

對於頻繁的記憶體調整，有幾個潛在的可用修復，請參閱：

10g 以前的版本可能存在的問題

10g 之前的版本，檢測 row cache 級別死鎖的方法有限。為了儘量減少發生死鎖的可能性，可能的解決方法：

• 設定 TIMED_STATISTICS=FALSE
• 設定 _row_cache_cursors=20 以上（預設值 10）
• 不要做任何 tracing

其他問題疑難解答

對於其他效能問題的故障排除,請參閱：

Bug 12772404 - Significant "row cache objects" latch contention when using VPD (Doc ID 12772404.8)

參考