How DRM works in RAC cluster
10g Real Application Clusters introduced a concept of resource remastering via Dynamic Resource Mastering (DRM). With DRM a resource can be re-mastered on another node in the cluster if it is found that the cache resource is accessed more frequently from that node.
With object remastering feature, if an object is accessed by an instance aggressively, then that instance will become the master of the object reducing gc remote grants improving performance of the application. In the prior sentence, I used the word “accessed”, but it is a loose term, and the correct term is if the instance is requesting much BL locks on an object, then that object can be remastered. In an ideal world, even if the application is not partitioned, remastering of the objects that were accessed aggressively from one instance will acquire cheaper local instance affinity locks and effective RAC Tax will be minimal.
In 10G R1 this was file based whereas the 10G R2 it is object based.
In 10G R1 due to a few bugs many related to high CPU usage during the DRM freeze window most customers disabled DRM by setting the following parameters
Parameters, views and internals
parameter _gc_affinity_time=0 (process LCK0 process maintains these object affinity statistics)
View X$object_affinity_statistics maintains the statistics about objects and OPENs on those objects.
_gc_affinity_time defines the frequency in minutes to check if remastering
_gc_affinity_limit defines the number of times a node must access an object
for it to be a DRM candidate it's meaning that _gc_affinity_time controls how often the queue is checked to see if the remastering must be triggered or not with a default value of 10 minutes.
_gc_affinity_minimum defines the minimum number of times an object is accessed per minute before affinity kicks in
The performance problems may manifest themselves in terms of a DRM related wait event like 'gcs drm freeze in enter server mode'
In 10G R2 this feature appears to be more stable.