细致入微：Oracle RAC DRM引起性能问题案例一则
熊军（老熊）
云和恩墨西区总经理
Oracle ACED，ACOUG核心会员
编辑手记：今天在『云和恩墨大讲堂』微信群，有朋友问到DRM问题，这让我想起老熊之前的一篇文章案例，虽然是关于Oracle 10g的，但是其思路和分析过程值得学习借鉴，收录在这里，供大家学习参考。
客户一套运行在Oracle 10.2.0.5 RAC上的系统，间歇性地出现性能问题。其性能现象为前台反映性能缓慢，从系统上看CPU利用率大幅增加，load增加。这种性能问题通常在出现几分钟后自动恢复正常。
从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个隐含参数：
_gc_affinity_time=0
_gc_undo_affinity=FALSE
不幸的是，这2个参数是静态参数，也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数，来达到这个目的。按下面的值设置这2个参数之后，不能完全算是禁止/关闭了DRM，而是从”事实上“关闭了DRM。
_gc_affinity_limit=250
_gc_affinity_minimum=10485760
甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的，在所有的节点上设置这2个参数之后，系统不再进行DRM，经常一段时间的观察，本文描述的性能问题也不再出现。
下面是关闭DRM之后的等待事件数据：
那么什么是DRM？DRM对系统来说有什么好处？下面的文档已经描述得比较清楚，有兴趣的朋友可以参考：
MOS文档：DRM - Dynamic Resource management [ID 390483.1]
DRM简单来说就是Oracle根据数据块的访问来动态调整管理数据块的主节点，这项技术在引入之初引发了一系列的性能问题。
搜索 盖国强（Eygle）微信号：eeygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。
关注本微信（OraNews）回复关键字获取 2016YHEMSZ ,云和恩墨大讲堂深圳交流会； 2016GOPSZ,2016深圳全球运维大会PPT； DBALife,"DBA的一天"精品海报大图； 12cArch,“Oracle 12c体系结构”精品海报； DBA01，《Oracle DBA手记》第一本下载； YunHe，“云和恩墨大讲堂”案例文档下载；