Oracle 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

参考文章：
DRM-Dynamic Resource management(Doc ID:390483.1)
Note 786048.1 11g RAC Best Practices