Oracle RAC Cache Fusion 系列十七：Oracle RAC DRM

SELECT KSPPINM  AS "hidden parameter",
       KSPPSTVL AS "value",
       KSPPDESC "description"
  FROM X$KSPPI
  JOIN X$KSPPCV
 USING (INDX)
 WHERE KSPPINM LIKE '\_%' ESCAPE '\'
   AND KSPPINM LIKE '_lm_%'
 ORDER BY KSPPINM;

10.1版本開始Oracle正式支援file affinity。10.2版本Oracle進行了最佳化將file affinity進行細化為object affinity及undo affinity，並記錄系統的負載資訊（預設由引數_lm_lhupd_interval控制）。file affinity由下面兩個引數來控制：

_gc_policy_time  ：單位為分鐘，控制DRM統計例項訪問buffer次數的時間間隔，預設為是10分鐘。

_gc_affinity_ratio：控制進行remastering所需要達到的最小比例（閥值），預設為50。也就是說，如果某個例項在10分鐘。

object affinity ：根據一段時間內（預設10分鐘），如果某一個例項訪問某個資料庫物件次數高於其他例項一定倍數（預設50倍），則oracle 會把這個物件所有的buffer的master資訊，轉移到對應例項（注意：不是轉移buffer）。當oracle 決定將一個buffer的master例項確定到本地例項後，會對這個buffer上加上affinity lock，來實現快速的訪問。

DRM過程會存在如下幾個階段：

1. Quiescs： Lmon通知所有例項，準備進行remastering。

2.Freeze： Oracle停止所有在需要進行remastering的buffer上的操作。

3. Cleanup： 在舊的master例項清除對應buffer的master資訊。

4. Rebuild： 將master資訊傳遞給新的master例項,在新的master例項構建資源的最新狀態。

5. Unfreeze： 結束，並釋放所有之前所有步驟佔用的資源。

注意：DRM是漸進的，也就是說以windows為單位，每次對一部分的buffer 進行remastering操作。

從這個流程我其實就知道DRM雖好但是存在的問題也很明顯，即在DRM過程中對涉及的資料塊的請求都將被阻塞。因此Oracle一直在不斷的最佳化DRM動作，希望能夠減少DRM帶來的影響。11g版本減少DRM給系統帶來的影響Oracle進行了如下幾處最佳化：

1.read-mostly locking（讀多寫少）： 簡單的說就是，對於某個物件，比如讀非常多，所有結點都會持有一個鎖，減少了共享鎖申請操作。而當需要寫操作時，需申請排它鎖時，在每個結點上都申請一個”anti-lock”鎖，可以理解為”反鎖”,然後再cache fusion。

2.reader bypass（寫少讀多）： 主要是為讀少寫多的業務進行的最佳化。reader bypass同樣引入了一種新的鎖模式weak X lock（又稱xw鎖）。可以在S鎖沒有釋放以前，為一個block加上一個xw鎖，對這個block進行修改，但是不允許立刻commit，直到所有的的S鎖都關閉或者降級到N鎖，LMS就會向xw鎖的持有者傳送一條資訊可以進行commit了。

3.Parallel DRM Freeze： 在DRM發生的過程中會存在凍結階段（Freeze）,即所有節點的LMS程式在收到LMON發出的訊息後，通知所有節點的LMS程式在結束master資訊遷移前不再接受對這些快的新的請求。那麼對於一個繁忙的系統這個過程是無法忍受的，因此Oracle引入了並行DRM加快master資訊的遷移速度，使用_drm_parallel_freeze引數控制，預設情況下啟用。

4.DRM Batch request： 批次處理DRM請求使用引數_lm_drm_batch_time控制，預設為10s。

5.DRM interval： 增大DRM觸發時間間隔，針對連續的DRM動作時間間隔至少為120s，由引數_lm_drm_min_interval控制。

6.Read Mostly資料固化： 早先版本針對DRM的ReadMostly系統統計資訊會隨著例項的重啟而被重置，為此從11.2.0.3版本開始，預設支援對read mostly的資料進行固化（透過_gc_persistent_read_mostly來實現)。

7.drm hiload： 在資料庫負載很高的情況下，會暫時禁用DRM，資料庫負載下降以後又重新啟用DRM,由引數_lm _drm_hiload_percentage和 _lm_drm_lowload_percentage引數控制預設為200 。

回滾段的Mastering和其它段不同，因為RAC環境中的每個例項均有各自自己的undo表空間。回滾段的remastering是不會因為另外一個節點對於回滾段有大量讀取而發生的。只有在某個例項失效，為了進行例項恢復的需要，叢集中負責進行例項恢復的其他例項會暫時的成為這些回滾段的master，然後進行例項的恢復動作。undo的remaster是由引數_gc_undo_affinity控制。

12C版本Oracle繼續對DRM進行最佳化，Oracle在進行資源凍結的時候並非凍結所有資源。 而是將資源分解為多個分割槽，以只凍結資源分割槽的這種方式極大地減少DRM相關等待的影響。 LMON一次只凍結一個資源分割槽。 第一個分割槽中的資源被凍結，完成資源重新建立任務，並解凍該資源分割槽。 然後凍結下一個資源分割槽並繼續，直到重新建立所有資源。 除此之外12c還引入了很多相關的Latch機制（gcsaffinity object freelist latch）和統計資訊連結串列（affinity statsobjects freelist ） ，Object的affinity stats資料是由lck0程式來進行維持，還引入了可以由使用者自定義read mostly例項的引數（_read_mostly_instance ,_read_mostly_instance_qa_control）。 

Parameter：_high_priority_processes

Value：LMS*|VKTM|LM*|LCK0|GCR*|DIAG