首先,我们对和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文件中,会看到类似如下信息:
- *** 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