oracle 10g RAC中DRM的理解
2014-08-18 15:10
399 查看
关于DRM的一些总结
1. 什么是DRM
DRM(Dynamic Resource Management)是oracle 10g的一个新特性,在oracle rac环境中,ORACLE使用GRD(Global Resource Service)来记录各个节点的资源信息,具体是通过GCS(Global Cache Service)和GES(Global Enqueue Service)这两个服务进行管理。由于RAC中每个节点都有自己的SGA和buffer cache,为了保证所有节点cache 资源的一致性和高性能。GCS和GES会指定RAC中的某一个节点的实例来管理cache,这个节点就是Resource
Master。当rematering或改变主节点只会发生在重新配置,会自动在两个正常操作实例启动或实例关闭,异常节点就是被集群踢出。所以当以节点A作为主节点是也就是 Resource Master时,这个资源就掌握在节点A中,直到被重新配置。
理论上讲,利用DRM,非master节点对所需资源有频繁访问需求时,可以提升为master节点,从而减少大量后续的跨节点资源访问需求,例:cache resource 被节点B频繁访问时,资源就可以从节点A remaster到节点B。
但是,作为一个好的RAC应用设计,同一个资源从多个节点访问本来就是应该避免的问题,如果访问的同一资源只在一个节点上,那么对于DRM来说,就根本不存在。其次,DRM过程本身就耗费资源。
/* 下面是老熊网站的一个例子:http://www.laoxiong.net/problem-caused-by-drm.html */
在一套RAC系统中,间歇性的出现性能问题,但是一段时间后自动恢复正常。
从AWR中的TOP 5等待来看:
可以看到,TOP 5中,有3个是latch相关的等待,而另外2个则是跟RAC相关的等待。
如果再查看更细的等待数据,可以发现其他问题:
从上面的数据还可以看到,除了TOP 5等待,还有”gcs drm freeze in enter server mode“以及”gc remaster”这2种比较少见的等待事件,从其名称来看,明显与DRM有关。那么这2种等待事件与TOP 5的事件有没有什么关联?。MOS文档”Bug 6960699 – “latch: cache buffers chains” contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/ OERI[kjbldrmrpst:!master] [ID
6960699.8]”提及,DRM的确可能会引起大量的”latch: cache buffers chains”、”latch: object queue header operation”等待,虽然文档没有提及,但不排除会引起”latch: cache buffers lru chain“这样的等待。
为了进一步证实性能问题与DRM相关,使用tail -f命令监控LMD后台进程的trace文件。在trace文件中显示开始进行DRM时,查询v$session视图,发现大量的 “latch: cache buffers chains” 、”latch: object queue header operation”等待事件,同时有”gcs drm freeze in enter server mode“和”gc remaster”等待事件,同时系统负载升高,前台反映性能下降。而在DRM完成之后,这些等待消失,系统性能恢复到正常。
看起来,只需要关闭DRM就能避免这个问题。怎么样来关闭/禁止DRM呢?很多MOS文档提到的方法是设置2个隐含参数:
不幸的是,这2个参数是静态参数,也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数,来达到这个目的。按下面的值设置这2个参数之后,不能完全算是禁止/关闭了DRM,而是从”事实上“关闭了DRM。
甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM,经常一段时间的观察,本文描述的性能问题也不再出现。
下面是关闭DRM之后的等待事件数据:
自己理解:DRM(Dynamic Resource Management)理论上实现了对非master的节点提升为master节点,可以减少跨节点资源访问,但是却带来了更多的问题。假如一个rac集群中有两个节点,节点2在空闲时段cache了一张很大很大的表,到了业务繁忙时段,节点1需要访问该表,如果没有DRM,则会从存储中访问,但是如果有了DRM,就会在节点2中找到该cache资源,从节点2的cache中将该资源传到节点1,这样的话就会消耗大量的带宽,从而消耗了很多资源。
1. 什么是DRM
DRM(Dynamic Resource Management)是oracle 10g的一个新特性,在oracle rac环境中,ORACLE使用GRD(Global Resource Service)来记录各个节点的资源信息,具体是通过GCS(Global Cache Service)和GES(Global Enqueue Service)这两个服务进行管理。由于RAC中每个节点都有自己的SGA和buffer cache,为了保证所有节点cache 资源的一致性和高性能。GCS和GES会指定RAC中的某一个节点的实例来管理cache,这个节点就是Resource
Master。当rematering或改变主节点只会发生在重新配置,会自动在两个正常操作实例启动或实例关闭,异常节点就是被集群踢出。所以当以节点A作为主节点是也就是 Resource Master时,这个资源就掌握在节点A中,直到被重新配置。
理论上讲,利用DRM,非master节点对所需资源有频繁访问需求时,可以提升为master节点,从而减少大量后续的跨节点资源访问需求,例:cache resource 被节点B频繁访问时,资源就可以从节点A remaster到节点B。
但是,作为一个好的RAC应用设计,同一个资源从多个节点访问本来就是应该避免的问题,如果访问的同一资源只在一个节点上,那么对于DRM来说,就根本不存在。其次,DRM过程本身就耗费资源。
/* 下面是老熊网站的一个例子:http://www.laoxiong.net/problem-caused-by-drm.html */
在一套RAC系统中,间歇性的出现性能问题,但是一段时间后自动恢复正常。
从AWR中的TOP 5等待来看:
<span style="font-size:12px;">Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- latch: cache buffers lru chain 774,812 140,185 181 29.7 Other gc buffer busy 1,356,786 61,708 45 13.1 Cluster latch: object queue header ope 903,456 55,089 61 11.7 Other latch: cache buffers chains 360,522 49,016 136 10.4 Concurrenc gc current grant busy 112,970 19,893 176 4.2 Cluster ------------------------------------------------------------- </span>
可以看到,TOP 5中,有3个是latch相关的等待,而另外2个则是跟RAC相关的等待。
如果再查看更细的等待数据,可以发现其他问题:
<span style="font-size:12px;"> Avg %Time Total Wait wait Waits Event Waits -outs Time (s) (ms) /txn ---------------------------- -------------- ----- ----------- ------- --------- latch: cache buffers lru cha 774,812 N/A 140,185 181 1.9 gc buffer busy 1,356,786 6 61,708 45 3.3 latch: object queue header o 903,456 N/A 55,089 61 2.2 latch: cache buffers chains 360,522 N/A 49,016 136 0.9 gc current grant busy 112,970 25 19,893 176 0.3 gcs drm freeze in enter serv 38,442 97 18,537 482 0.1 gc cr block 2-way 1,626,280 0 15,742 10 3.9 gc remaster 6,741 89 12,397 1839 0.0 row cache lock 52,143 6 9,834 189 0.1 </span>
从上面的数据还可以看到,除了TOP 5等待,还有”gcs drm freeze in enter server mode“以及”gc remaster”这2种比较少见的等待事件,从其名称来看,明显与DRM有关。那么这2种等待事件与TOP 5的事件有没有什么关联?。MOS文档”Bug 6960699 – “latch: cache buffers chains” contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/ OERI[kjbldrmrpst:!master] [ID
6960699.8]”提及,DRM的确可能会引起大量的”latch: cache buffers chains”、”latch: object queue header operation”等待,虽然文档没有提及,但不排除会引起”latch: cache buffers lru chain“这样的等待。
为了进一步证实性能问题与DRM相关,使用tail -f命令监控LMD后台进程的trace文件。在trace文件中显示开始进行DRM时,查询v$session视图,发现大量的 “latch: cache buffers chains” 、”latch: object queue header operation”等待事件,同时有”gcs drm freeze in enter server mode“和”gc remaster”等待事件,同时系统负载升高,前台反映性能下降。而在DRM完成之后,这些等待消失,系统性能恢复到正常。
看起来,只需要关闭DRM就能避免这个问题。怎么样来关闭/禁止DRM呢?很多MOS文档提到的方法是设置2个隐含参数:
<span style="font-size:12px;">_gc_affinity_time=0 _gc_undo_affinity=FALSE </span>
不幸的是,这2个参数是静态参数,也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数,来达到这个目的。按下面的值设置这2个参数之后,不能完全算是禁止/关闭了DRM,而是从”事实上“关闭了DRM。
<span style="font-size:12px;">_gc_affinity_limit=250 _gc_affinity_minimum=10485760 </span>
甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM,经常一段时间的观察,本文描述的性能问题也不再出现。
下面是关闭DRM之后的等待事件数据:
<span style="font-size:12px;">Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- CPU time 15,684 67.5 db file sequential read 1,138,905 5,212 5 22.4 User I/O gc cr block 2-way 780,224 285 0 1.2 Cluster log file sync 246,580 246 1 1.1 Commit SQL*Net more data from client 296,657 236 1 1.0 Network ------------------------------------------------------------- Avg %Time Total Wait wait Waits Event Waits -outs Time (s) (ms) /txn ---------------------------- -------------- ----- ----------- ------- --------- db file sequential read 1,138,905 N/A 5,212 5 3.8 gc cr block 2-way 780,224 N/A 285 0 2.6 log file sync 246,580 0 246 1 0.8 SQL*Net more data from clien 296,657 N/A 236 1 1.0 SQL*Net message from dblink 98,833 N/A 218 2 0.3 gc current block 2-way 593,133 N/A 218 0 2.0 gc cr grant 2-way 530,507 N/A 154 0 1.8 db file scattered read 54,446 N/A 151 3 0.2 kst: async disk IO 6,502 N/A 107 16 0.0 gc cr multi block request 601,927 N/A 105 0 2.0 SQL*Net more data to client 1,336,225 N/A 91 0 4.5 log file parallel write 306,331 N/A 83 0 1.0 gc current block busy 6,298 N/A 72 11 0.0 Backup: sbtwrite2 4,076 N/A 63 16 0.0 gc buffer busy 17,677 1 54 3 0.1 gc current grant busy 75,075 N/A 54 1 0.3 direct path read 49,246 N/A 38 1 0.2 </span>
自己理解:DRM(Dynamic Resource Management)理论上实现了对非master的节点提升为master节点,可以减少跨节点资源访问,但是却带来了更多的问题。假如一个rac集群中有两个节点,节点2在空闲时段cache了一张很大很大的表,到了业务繁忙时段,节点1需要访问该表,如果没有DRM,则会从存储中访问,但是如果有了DRM,就会在节点2中找到该cache资源,从节点2的cache中将该资源传到节点1,这样的话就会消耗大量的带宽,从而消耗了很多资源。
相关文章推荐
- Oracle 10g RAC中的DRM问题及关闭
- Oracle 10g RAC中的DRM问题及关闭
- Oracle 10g RAC中的DRM问题及关闭
- Oracle 10g RAC中的DRM
- Oracle 10g RAC中的DRM问题及关闭
- Oracle 10g RAC的负载均衡配置
- ORACLE 10G RAC的存储选项
- 在Solaris 10 X86上安装Oracle 10g RAC详解 (1)
- 在RedHat AS 4下安装Oracle 10G RAC遇到的问题集
- 在redhat as4上单机模拟Oracle 10g RAC集群(OCFS+ASM)
- Build Your Own Oracle RAC 10g Release 2 Cluster on Linux and FireWire
- Oracle 10G RAC下OCR和Voting disk的管理
- Oracle 10g R2 RAC 安装配置说明书
- Oracle Clusterware及Rac管理及部署指南10g Release 2
- RHEL AS 4 U4安装ORACLE 10g RAC碰到的问题(VMware server)
- hpux+slvm+mc/sg+oracle 10g rac实施手册
- ORACLE 10g RAC SGA自动管理模式下如何固定db buffer cache和shared pool的大小
- 在Solaris 10 X86上安装Oracle 10g RAC详解 (2)
- 在linux上单机模拟Oracle 10g RAC集群(OCFS+ASM)
- oracle 10G R2 RAC 数据库的关闭与启动