共計 2136 個字符，預計需要花費 6 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關如何理解 oracle 11g DRM，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
DRM 簡介
首先，我們對和 DRM 相關的一些概念進行介紹。
Buffer: 對于 RAC 數據庫，當一個數據塊被讀入到 buffer cache 后，我們就稱其為 buffer , cache fusion 會將這個 buffer 作為 resource 來管理。
Master：在 RAC 數據庫的世界里，每一個 resource 都會有一個 master 實例，這個 master 實例會在 shared pool 中（例如：gcs resource 和 ges resource 部分）分配一些空間來存放和這個資源相關的信息，例如：哪一個實例擁有了這個 buffer 的最新版本，哪一個實例擁有了這個 buffer 的什么級別的 lock 等等。并且，負責維護和這個資源的狀態。
接下來，我們對 RAC 環境中，訪問一個 buffer 的過程進行簡單的描述。我們以一個 4 節點的 RAC 數據庫為例。注意，我們只會列出比較典型的一種情況，不會把所有可能的情況都一一列出，而且只是把步驟進行了簡單的介紹。
步驟 1：實例 3 需要以 X(exclusive) 方式訪問 buffer1, 向 master 實例（1）發出了請求。
步驟 2：master 實例（1）發現實例 2 以 X 方式持有 buffer1，之后通知實例 2 釋放 X lock，并把 buffer1 發送給實例 3。
步驟 3: 實例 2 釋放 X lock，并把最新版本的 buffer1 發送給實例 3。
步驟 4：實例 3 獲得 buffer1, 并通知 master 實例（1）更新資源 buffer1 的最新狀態。
從上面的步驟，我們不難看出，在 RAC 數據庫中，當我們訪問一個 buffer 的時候，最多會有 3 個實例參與其中，master 實例，holder（持有者）實例 和 requestor(申請者) 實例。2 種數據傳輸會出現，message: 用于和 lock 相關的信息傳輸，data：用于傳輸 buffer。同時，根據上面的步驟我們也自然會想到，如果 master 和 requestor 在同一個實例上，那么就可以減少實例之間 message 的傳輸并且訪問的代碼路徑（code path）會更短，從而提高性能，但是每個 buffer 在被讀取到 buffer cache 時，master 節點的選擇是隨機的。基于這種考慮，oracle 從 10g 開始，推出了一個新特性 DRM（Dynamic Resource management）。
DRM 的主要功能是，根據一段時間內（默認 10 分鐘），每個實例，對某一個數據庫對象的 (10gR1 以數據文件為單位) 的訪問次數和方式，來決定數據庫對象對應的 buffer 應該被 mastering 到哪一個實例。在指定時間內，如果某一個實例訪問某個數據庫對象次數高于其他實例一定倍數（默認 50 倍），則 oracle 會把這個對象所有的 buffer 的 master 信息，轉移到對應實例（注意：不是轉移 buffer）。當然，轉移的過程是漸進式的。當 oracle 決定將一個 buffer 的 master 實例確定到本地實例后，會對這個 buffer 上加上 affinity lock，來實現快速的訪問。這也是我們經常提到的 object affinity 的由來。
接下來，我們對 DRM 的基本步驟進行介紹。
1． Oracle 停止所有在需要進行 remastering 的 buffer 上的操作。注意：DRM 是漸進的，也就是說以 windows 為單位，每次對一部分的 buffer 進行 remastering 操作。
2． Lmon 通知所有實例，準備進行 remastering
3． 在舊的 master 實例清除對應 buffer 的 master 信息
4． 將 master 信息傳遞給新的 master 實例
5． 在新的 master 實例構建資源的最新狀態
6． 結束，并釋放所有之前所有步驟占用的資源。
然后，我們對 DRM 相關的一些參數進行簡單的介紹。
_gc_policy_time：單位為分鐘，控制 DRM 統計實例訪問 buffer 次數的時間間隔，默認為是 10 分鐘。
_gc_affinity_ratio：控制進行 remastering 所需要達到的最小比例（閥值），默認為 50。也就是說，如果某個實例在 10 分鐘（_gc_policy_time）之內，訪問某個數據庫對象的次數大于其他所有實例 50 倍時 (注意：是 50 倍，而不是 50 次)，對該數據庫對象的 buffer 進行 remastering。
注意：請不要修改以上參數的值，除非您很清楚自己在做什么，或者是根據 oracle 工程師的建議。
最后，如果您遇到了和 DRM 相關的問題，建議您查看以下的信息。
1. Lmon，lmd，lms 和 diag 進程的 trace file，來確認問題出現在 DRM 的哪一步和 lms,lmon,lmd 進程的狀態。
2. AWR 和 ASH report，確認那些等待事件持續了很長時間，以及 lmon,lms 和 lmd 的狀態。
3. 參照 note 1492990.1 獲取 DMR 診斷腳本輸出。
上述就是丸趣 TV 小編為大家分享的如何理解 oracle 11g DRM 了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
