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文件中，会看到类似如下信息：
*** 2013-12-25 00:58:39.185
Begin DRM(27)
sent syncr inc 4 lvl 809 to 0 (4,0/31/0)
sent synca inc 4 lvl 809 (4,0/31/0)
sent syncr inc 4 lvl 810 to 0 (4,0/34/0)
sent synca inc 4 lvl 810 (4,0/34/0)
sent syncr inc 4 lvl 811 to 0 (4,0/36/0)
...
kjfcdrmrfg:SYNC TIMEOUT(25554,25369,800),STEP 45
...
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提出
用如下一脚本查看
SELECT KSPPINM AS "hidden parameter",
KSPPSTVL AS "value",
KSPPDESC "description"
FROM X$KSPPI
JOIN X$KSPPCV
USING (INDX)
WHERE KSPPINM LIKE '\_%' ESCAPE '\'
AND KSPPINM LIKE
'_lm_dynamic%'
ORDER BY KSPPINM;
会看到如下几个参数
hidden parameter value description
------------------------ -------
------------------------------------
_lm_dynamic_lms FALSE dynamic lms
invocation
_lm_dynamic_load TRUE dynamic
load adjustment
_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节点。具体的阈值可以由以下两个参数来决定：
_gc_affinity_time (if non zero, enable dynamic object
affinity(缺省值10分钟))
_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：
11.2.0.3.5
13732226 RAC node eviction dur to "TIMEOUT in DRM FREEZE step" or
"SYNC TIMEOUT"
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:
_gc_affinity_time=0
_gc_undo_affinity=FALSE
如果想不停库临时关掉，上面两个参数设一下很大值就可以了，这样大大减小DRM被触发的机率了。
例如：
alter system set "_gc_affinity_limit"=5000000;
alter system set "_gc_affinity_minimum"=5000000;
Oracle 11g:
_gc_policy_time=0
如果不想完全禁用DRM，仅禁用read-mostly locking或者reader bypass的机制。可以这样：
禁用read-mostly locking:
alter system set "_gc_read_mostly_locking"=false scope=spfile;
禁用reader-bypass:
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测算：
SQL> SELECT round(A.VALUE / (A.VALUE + B.VALUE)*100,2)||'%'
gcs_local_pct
2 FROM
(SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('gc local
grants')) A,
3 (SELECT
NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('gc remote grants'))
B
4 /
GCS_LOCAL_PCT
--------------------
82.52%
这是一个两结点的RAC,从概率学的角度这个值为50%,现在为82.52%,说明DRM还是很有作用的。
8
相关视图及等待事件
新增视图：
x$kjdrmafnstats DRM的次数及平均操作延时等统计信息
x$object_affinity_statistics LCK进程维护的基于每个对象的统计信息
v$gcspfmaster_info 一些发生了DRM对象的master信息
等待事件：
在对象DRM期间访问该对象可能会遇到如下等待事件：
gc remaster
gcs drm freeze in enter server mode
参考文章：
DRM-Dynamic Resource management(Doc ID:390483.1)
Note 786048.1 11g RAC Best Practices