Oracle DRM原理介紹

DRM 相關的一些概念進行介紹

本文轉載自官方部落格，作者Allen Gao

https://blogs.oracle.com/database4cn/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

注意：請不要輕易修改以上引數的值，除非有技術支援

最後，如果您遇到了和DRM相關的問題，建議您檢視以下的資訊。

1. Lmon，lmd，lms和diag程式的 trace file，來確認問題出現在DRM的哪一步和lms,lmon,lmd程式的狀態。

2. AWR 和ASH report，確認那些等待事件持續了很長時間，以及lmon,lms 和lmd的狀態。

3. 參照note 1492990.1 獲取 DMR 診斷指令碼輸出。