在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推出的自动负载平衡一样，只是一种看起来很美的东西，如果真的有人用了，呵呵，那就只能等死吧。或许压力极小的数据库无所谓，但我没遇到过，话又说回来，压力极小，又何必上RAC呢。
为了技术而技术，不是我们的最终目的，科技以人为本，技术也一样，人，才是最重要的决定因素。