在rac环境中，oracle使用grd（global resource service）来记录各个rac节点的资源信息，具体通过gcs（global cache service）和g
在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呢。
为了技术而技术，不是我们的最终目的，科技以人为本，技术也一样，人，才是最重要的决定因素。