Oracle 10g RAC中的DRM問題及關閉

在RAC環境中，Oracle使用GRD（Global Resource Service）來記錄各個RAC節點的資源信息，具體通過GCS（Global Cache Service）和GES（Global Enqueue Service）這兩個服務進行管理。

由于在RAC中每個節點都有自己的SGA和buffer cache，為了保證Cache資源的一致性和提高性能，GCS和GES會指定RAC中的一個instance來管理Cache，這個節點這時就是Resource Master。
-
 

在10g以前，Cache資源是不能在各個節點間移動的，除非重啟或者某節點因為其他異常被RAC驅逐等情況。而10g的DRM就解決了這個問題，它可以保證cache能夠被remaster到頻繁訪問這部分數據的節點上，從而提高RAC的性能。DRM的全稱是Dynamic Resource Mastering，metalink上的Doc ID:  390483.1文檔詳細介紹了DRM的信息。

從理論上講，利用此項技術，非master節點對所需資源有頻繁訪問需求時，www.linuxidc.com可以提升為master節點，從而減少大量后續的跨節點資源訪問需求。

但是，首先從根本上說，一個好的RAC應用設計，本就應該極盡所能的取避免同一資源的多節點訪問，如果不存在同一資源的多節點訪問，則DRM所要解決的問題，就根本不存在。其次，DRM本身是需要消耗資源的，并且存在諸多bug，對于一個設計較差的系統而言，頻繁的DRM，也會引發Libary cache lock而導致實例掛住。

更嚴重的，在10.2.0.3系統上，曾經遇到一個case，電信行業的巨型數據庫，rac的2號節點由于批量處理作業在非業務時間段，首先cache了一張40G的表，而到了業務時間段后，rac的1號節點的OLTP業務需要頻繁訪問該表，此時，故障發生了，由于DRM的介入，2號節點開始將內存內的40Gcache數據向1號節點傳輸，心跳網段千兆帶寬被耗盡，RAC陷入僵死階段，足足維持了40分鐘。

事后檢查網絡流量圖，該時段內，私有網絡流量持續保持在90M/s的峰值水平。

根據metalink確認，該問題確實由DRM機制引起，最終解決方案，使用隱含參數，將DRM特性屏蔽：

_gc_affinity_time=0

_gc_undo_affinity=FALSE

因此，從根本上來說，drm的出現，只是在理論上的一種緩解，而并不能在實際的大型應用中發揮其作用。就類似于Oracle自己針對RAC推出的自動負載平衡一樣，只是一種看起來很美的東西，如果真的有人用了，呵呵，那就只能等死吧�；蛟S壓力極小的數據庫無所謂，但我沒遇到過，話又說回來，壓力極小，又何必上RAC呢。

為了技術而技術，不是我們的最終目的，科技以人為本，技術也一樣，人，才是最重要的決定因素。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]