由row cache lock等待事件引起的效能問題

客戶反映登入資料庫緩慢，檢查v$session_wait檢視發現有大量row cache lock等待事件。從ash報告中也可以看到row cache lock等待事件比較明顯
Top User Events
Event Event Class % Activity Avg Active Sessions
row cache lock Concurrency 77.90 33.49
cursor: pin S wait on X Concurrency 22.00 9.46

ROW CACHE LOCK等待事件是一個共享池相關的等待事件。是由於對於字典緩衝的訪問造成的。
P1 – Cache Id
P2 – Mode Held
P3 – Mode Requested

mode 和REQUEST的取值：
KQRMNULL 0 null mode – not locked
KQRMS 3 share mode
KQRMX 5 exclusive mode
KQRMFAIL 10 fail to acquire instance lock

如果是RAC/OPS環境，前臺程式發出鎖請求，LCK0程式發出鎖請求。如果是單例項模式，由前臺程式直接發出鎖請求。
在RAC/OPS環境下，前臺程式會迴圈等待鎖的獲取，最多會等待60秒鐘。在單例項環境，前臺程式會迴圈1000次，等待3秒鐘。PMON程式無論在哪種模式，都會等待5秒鐘。
要注意的是單例項模式下和多例項模式下申請該鎖呼叫的模組是不同的（kqrget()- 單例項，kqgigt()- 多例項）。
如果發現這個等待十分高，一般來說可能由於2種原因，一是共享池太小了，需要增加共享池，
另外一種情況是SQL分析過於頻繁，對於共享池的併發訪問量過大。
對於任何一種情況，絕大多數情況下加大共享池會有助於降低該等待，不過加大共享池的時候也要注意，並不一定所有的情況下增加共享池都會有明顯的效果，特別是對於第二種情況，精確的分析十分重要。另外進一步分析，弄清楚哪些ROW CACHE的等待最為嚴重，有助於解決問題。

通過ASH報告的主機資訊，發現shared pool只有776M，感覺像是共享池過小問題。
CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size
4 6,144M (100%) 5,216M (84.9%) 776M (12.6%) M (%)
通過檢查發現資料庫SGA設定為6G，其中BUFFER CACHE設定最小為5G (db_cache_size=5G)。
調整db_cache_size引數為0，讓資料庫自動調整。該問題解決。

參考資料：
惜分飛的《ROW CACHE LOCK等待事件》

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