916
細致入微：Oracle RAC DRM引起性能問題案例一則
熊軍（老熊）
雲和恩墨西區總經理
Oracle ACED，ACOUG核心會員
編輯手記：今天在『雲和恩墨大講堂』微信群，有朋友問到DRM問題，這讓我想起老熊之前的一篇文章案例，雖然是關於Oracle 10g的，但是其思路和分析過程值得學習借鑒，收錄在這裏，供大家學習參考。
客戶一套運行在Oracle 10.2.0.5 RAC上的係統，間歇性地出現性能問題。其性能現象為前台反映性能緩慢，從係統上看CPU利用率大幅增加，load增加。這種性能問題通常在出現幾分鍾後自動恢複正常。
從AWR中的TOP 5等待來看：
可以看到，TOP 5中，有3個是latch相關的等待，而另外2個則是跟RAC相關的等待。
如果再查看更細的等待數據，可以發現其他問題：
從上麵的數據還可以看到，除了TOP 5等待，還有：
"gcs drm freeze in enter server mode“以及"gc remaster"
這2種比較少見的等待事件，從其名稱來看，明顯與DRM有關。那麼這2種等待事件與TOP 5的事件有沒有什麼關聯？。
MOS文檔：
"Bug 6960699 - "latch: cache buffers chains" contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/ OERI[kjbldrmrpst:!master] [ID 6960699.8]”
提及，DRM的確可能會引起大量的"latch: cache buffers chains"、"latch: object queue header operation"等待，雖然文檔沒有提及，但不排除會引起”latch: cache buffers lru chain“這樣的等待。
為了進一步證實性能問題與DRM相關，使用tail -f命令監控LMD後台進程的trace文件。
在trace文件中顯示開始進行DRM時，查詢v$session視圖，發現大量的 "latch: cache buffers chains" 、"latch: object queue header operation"等待事件，同時有"gcs drm freeze in enter server mode“和"gc remaster"等待事件，同時係統負載升高，前台反映性能下降。
而在DRM完成之後，這些等待消失，係統性能恢複到正常。
看起來，隻需要關閉DRM就能避免這個問題。怎麼樣來關閉/禁止DRM呢？很多MOS文檔提到的方法是設置2個隱含參數：
_gc_affinity_time=0
_gc_undo_affinity=FALSE
不幸的是，這2個參數是靜態參數，也就是說必須要重啟實例才能生效。
實際上可以設置另外2個動態的隱含參數，來達到這個目的。按下麵的值設置這2個參數之後，不能完全算是禁止/關閉了DRM，而是從”事實上“關閉了DRM。
_gc_affinity_limit=250
_gc_affinity_minimum=10485760
甚至可以將以上2個參數值設置得更大。這2個參數是立即生效的，在所有的節點上設置這2個參數之後，係統不再進行DRM，經常一段時間的觀察，本文描述的性能問題也不再出現。
下麵是關閉DRM之後的等待事件數據：
那麼什麼是DRM？DRM對係統來說有什麼好處？下麵的文檔已經描述得比較清楚，有興趣的朋友可以參考：
-
MOS文檔：DRM - Dynamic Resource management [ID 390483.1]
DRM簡單來說就是Oracle根據數據塊的訪問來動態調整管理數據塊的主節點，這項技術在引入之初引發了一係列的性能問題。
本文出自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 18:04:16