在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節點對所需資源有頻繁訪問需求時，可以提升為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推出的自動負載平衡一樣，只是一種看起來很美的東西，如果真的有人用了，呵呵，那就只能等死吧。或許壓力極小的資料庫無所謂，但我沒遇到過，話又說 回來，壓力極小，又何必上RAC呢。        為了技術而技術，不是我們的最終目的，科技以人為本，技術也一樣，人，才是最重要的決定因素。

zhuanzai :http://cjjwzs.iteye.com/blog/1159086