DRM 简介

首先，我们对和DRM 相关的一些概念进行介绍。
Buffer: 对于RAC 数据库，当一个数据块被读入到buffer cache后，我们就称其为buffer , cache fusion 会将这个buffer作为resource来管理。

Master：在RAC 数据库的世界里，每一个resource都会有一个master实例，这个master实例会在shared pool 中（例如：gcs resource 和ges resource 部分）分配一些空间来存放和这个资源相关的信息，例如：哪一个实例拥有了这个buffer的最新版本，哪一个实例拥有了这个buffer的什么级别的lock等等。并且，负责维护和这个资源的状态。

接下来，我们对RAC 环境中，访问一个buffer的过程进行简单的描述。我们以一个4节点的RAC 数据库为例。注意，我们只会列出比较典型的一种情况，不会把所有可能的情况都一一列出，而且只是把步骤进行了简单的介绍。

步骤1：实例3需要以X(exclusive)方式访问buffer1, 向master实例（1） 发出了请求。
步骤2：master实例（1）发现实例2 以X方式持有buffer1，之后通知实例2释放X lock，并把buffer1发送给实例3。
步骤3: 实例2释放X lock，并把最新版本的buffer1发送给实例3。
步骤4：实例3获得buffer1, 并通知master 实例（1）更新资源buffer1的最新状态。

从上面的步骤，我们不难看出，在RAC 数据库中，当我们访问一个buffer的时候，最多会有3个实例参与其中，master实例，holder（持有者）实例 和requestor(申请者) 实例。2种数据传输会出现，message:用于和lock相关的信息传输，data：用于传输buffer。同时，根据上面的步骤我们也自然会想到，如果master和requestor在同一个实例上，那么就可以减少实例之间message的传输并且访问的代码路径（code path）会更短，从而提高性能，但是每个buffer在被读取到buffer cache时，master节点的选择是随机的。基于这种考虑， oracle从10g开始，推出了一个新特性DRM（Dynamic Resource management）。

DRM的主要功能是，根据一段时间内（默认10分钟），每个实例，对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式，来决定数据库对象对应的buffer应该被mastering 到哪一个实例。在指定时间内，如果某一个实例访问某个数据库对象次数高于其他实例一定倍数（默认50倍），则oracle 会把这个对象所有的buffer的master信息，转移到对应实例（注意：不是转移buffer）。当然，转移的过程是渐进式的。当oracle 决定将一个buffer的master实例确定到本地实例后，会对这个buffer上加上affinity lock，来实现快速的访问。这也是我们经常提到的object affinity 的由来。

接下来，我们对DRM的基本步骤进行介绍。
1． Oracle停止所有在需要进行remastering的buffer上的操作。注意：DRM是渐进的，也就是说以windows 为单位，每次对一部分的buffer 进行remastering 操作。
2． Lmon 通知所有实例，准备进行remastering
3． 在旧的master实例清除对应buffer的master信息
4． 将master信息传递给新的master实例
5． 在新的master实例构建资源的最新状态
6． 结束，并释放所有之前所有步骤占用的资源。

然后，我们对DRM相关的一些参数进行简单的介绍。
_gc_policy_time ：单位为分钟，控制DRM统计实例访问buffer次数的时间间隔，默认为是10分钟。
_gc_affinity_ratio：控制进行remastering所需要达到的最小比例（阀值），默认为50。也就是说，如果某个实例在10分钟（_gc_policy_time）之内，访问某个数据库对象的次数大于其他所有实例50倍时(注意：是50倍，而不是50次)，对该数据库对象的buffer进行remastering。

注意：请不要修改以上参数的值，除非您很清楚自己在做什么，或者是根据oracle 工程师的建议。

最后，如果您遇到了和DRM相关的问题，建议您查看以下的信息。
1. Lmon，lmd，lms和diag进程的 trace file，来确认问题出现在DRM的哪一步和lms,lmon,lmd进程的状态。
2. AWR 和ASH report，确认那些等待事件持续了很长时间，以及lmon,lms 和lmd的状态。
3. 参照note 1492990.1 获取 DMR 诊断脚本输出。

希望以上的介绍对理解DRM有些帮助

转自：https://blogs.oracle.com/database4cn/drm

另外一篇讲的也不错

1 前言
谈及DRM,好些人很陌生，又有一些人很兴奋。陌生的比较幸运，没遭遇过DRM BUG，。兴奋的人可能是被DRM折磨过,或是喜欢钻研Oracle技术。这是Oracle的一个新特性，Oracle 9i中提出，到10g时堂而皇之出现，到11g不断的优化完善.DRM被很多人评价为”臭名昭著”，所以在安装完Oracle RAC后不分青红皂白立即把DRM功能给关了，心想着从此高枕无忧了，我属于这一类，吃苹果打皮，虽然很多人说果皮很有营养，我坚持宁可不吸收这营养也不吸收毒素。
可换一种思维想一想，存在即合理，从Oracle 10g DRM被Oracle使用，虽然各色满屏的BUG这一特性也没被Oracle废弃掉，Oracle还不断的绞尽脑汁的完善这样一功能，说明这样的功能对于特定的情形是会获得很大性能收益的，这里不戴有色眼睛，客观的描述DRM的相关知识，使得我们在实践工作中更好的利用它。

2 DRM为何”臭名昭著”
自Oracle 10g正式引入DRM以来，这个新特性引发了很多故障，主要表现为DRM sync timeout，即同步超时，同时DRM需要LCK、LMD、LMS等进程的协作，某一环节由于BUG会引起DRM失败。一些严重的情况会使LMON及PMON等关键进程遇到481错误，进而导致实例被逐出，实例崩溃。在LMON的trace文件中，会看到类似如下信息：

1. *** 2013-12-25 00:58:39.185
2. Begin DRM(27)
3. sent syncr inc 4 lvl 809 to 0 (4,0/31/0)
4. sent synca inc 4 lvl 809 (4,0/31/0)
5. sent syncr inc 4 lvl 810 to 0 (4,0/34/0)
6. sent synca inc 4 lvl 810 (4,0/34/0)
7. sent syncr inc 4 lvl 811 to 0 (4,0/36/0)
8. ...
9. kjfcdrmrfg:SYNC TIMEOUT(25554,25369,800),STEP 45
10. ...
11. ORA-481:LMON process terminated with error

3 DRM设计初衷
DRM展开为Dynamic Remastering，意思就是动态重新指定宿主，听着还是让人糊涂。实际Oracle本来也没想让普通用户明白，因为Oracle官方文档没有DRM任何信息。
在Oracle RAC中，每个数据块都有管理结点，我们称之为master，Oracle对每个数据块DBA（data block address）进行hash运算来决定其master。在Oracle 9i RAC,在一个比较繁忙的RAC生产系统上，db file scatter/sequential read总是很多，同时还会伴随有global cache cr request等待事件，而且这两者成正比的关系。因为在执行一SQL时，总有一些数据库的master是remote node,所以global cache cr request不可避免。访问remote node管理的数据块需要发出grant类请求信息，会伴有gc cr/current grant xxx等待，如果数据库的master是local node,那上面的交换就省了，从而减少访问块的代价。

4 DRM的前世今生
9i DRM提出
用如下一脚本查看

1. SELECT KSPPINM  AS "hidden parameter",
2.        KSPPSTVL AS "value",
3.        KSPPDESC "description"
4.   FROM X$KSPPI
5.   JOIN X$KSPPCV
6.  USING (INDX)
7.  WHERE KSPPINM LIKE '\_%' ESCAPE '\'
8.    AND KSPPINM LIKE '_lm_dynamic%'
9.  ORDER BY KSPPINM;

会看到如下几个参数

1. hidden parameter         value   description
2. ------------------------ ------- ------------------------------------
3. _lm_dynamic_lms          FALSE   dynamic lms invocation
4. _lm_dynamic_load         TRUE    dynamic load adjustment
5. _lm_dynamic_remastering  FALSE   if TRUE enables dynamic remastering

可见已有_lm_dynamic_remastering这个参数，不过未启用。

DRM功能的真正实现是始于10.1，支持file affinity,不过条件较高，实际中只有很少量的remastering，以至于很多人都没感觉到它的存在。

到了10gR2, file affinity进一步演化为更细粒度的object affinity，并且同时引入了undo affinity，只要满足隐含参数要求DRM就会被使用，实际观察会发现有很多的remastering。
object affinity机制：
简单的说就是，哪个节点访问这个object多，就由哪个节点来充当master节点。具体的阈值可以由以下两个参数来决定：

1. _gc_affinity_time （if non zero, enable dynamic object affinity(缺省值10分钟)）
2. _gc_affinity_limit  （dynamic affinity limit (default = 50)）

从默认值可以知道， DRM的临界条件为在10分钟以内，某结点访问一个文件/对象的次数比另外一个节点多50次，那么这个节点就会成为此object的master节点的候选。需要说明的是如果数据库重启了，过往的remastering都白折腾了，重新hash，重新开始。

11g开始，Oracle为DRM进行了大量优化工作，最重要的两个就是read-mostly locking以及reader bypass。
read-mostly locking:
简单的说就是，对于某个对象，比如读非常多，预先给它加一层共享访问锁，所有结点都持有，因而减少了共享锁的申请操作。而当需要写操作时，需申请排它锁时，在每个结点上都申请一个”anti-lock”锁，可以理解为”反锁”,然后再cache fusion。
reader bypass：
read-mostly locking是互斥的，主要是为读少写多的业务进行的优化。reader bypass同样引入了一种新的锁模式weak X lock（又称xw锁）。可以在S锁没有释放以前，为一个block加上一个xw锁，对这个block进行修改，但是不允许立刻commit，直到所有的的S锁都关闭或者降级到N锁，LMS就会向xw锁的持有者发送一条信息可以进行commit了。

5 是否该弃用DRM
google或baidu一下，会发现很多人讲DRM,同时罗列了Oracle各个版本DRM大量的BUG,
例如，10.2.0.3.5这个版本关于DRM还有如下BUG：

1. 11.2.0.3.5
2. 13732226 RAC node eviction dur to "TIMEOUT in DRM FREEZE step" or "SYNC TIMEOUT"
3. 13399435 RAC instance eviction due to "TIMEOUT in DRM FREEZE step" or "SYNC TIMEOUT ..."

是否该弃用呢？我的回答是看你是否遭遇到过DRM的问题，如果你的RAC运行很稳定，自己都没感觉到有DRM这个东西的存在，可以继续使用。某个路段的坑很多，而你从来也不走那条路，那管它是否有坑呢。
如果你的RAC因DRM的BUG宕过，或是一个没打过丁的裸奔版本，要么升级补丁要么就把DRM弃用吧。

6 如何关闭DRM
通过设置隐含参数的方式完成
Oracle 10g:

1. _gc_affinity_time=0
2. _gc_undo_affinity=FALSE

如果想不停库临时关掉，上面两个参数设一下很大值就可以了，这样大大减小DRM被触发的机率了。
例如：

1. alter system set "_gc_affinity_limit"=5000000;
2. alter system set "_gc_affinity_minimum"=5000000;

Oracle 11g:

1. _gc_policy_time=0

如果不想完全禁用DRM，仅禁用read-mostly locking或者reader bypass的机制。可以这样：
禁用read-mostly locking:

1. alter system set "_gc_read_mostly_locking"=false scope=spfile;

禁用reader-bypass:

1. alter system set "_gc_bypass_readers"=false scope=spfile;

7 GCS resource访问本地化比例统计
想测一下DRM的实际作用，Oracle给出了GCS resource访问本地化比例统计指标
GCS resource访问本地化比例统计=（local mastered buffer/all cache buffer）
可以使用如下SQL测算：

1. SQL> SELECT round(A.VALUE / (A.VALUE + B.VALUE)*100,2)||'%' gcs_local_pct
2.   2    FROM (SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('gc local grants')) A,
3.   3         (SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('gc remote grants')) B
4.   4  /
5. GCS_LOCAL_PCT
6. --------------------
7. 82.52%

这是一个两结点的RAC,从概率学的角度这个值为50%,现在为82.52%,说明DRM还是很有作用的。

8 相关视图及等待事件
新增视图：

1. x$kjdrmafnstats DRM的次数及平均操作延时等统计信息
2. x$object_affinity_statistics LCK进程维护的基于每个对象的统计信息
3. v$gcspfmaster_info  一些发生了DRM对象的master信息

等待事件：
在对象DRM期间访问该对象可能会遇到如下等待事件：

1. gc remaster
2. gcs drm freeze in enter server mode

转自：http://www.qiuyb.com/archives/110