在RAC 11.2.0.4生产环境中，每天某个时间，MQ发生大量交易堵塞，从原先的每分钟2千多笔，掉到1千多笔，从数据库后台监控来看，集群GC出现大量堵塞。怀疑RAC发生DRM。
从官方文档中，理解DRM机制，RAC每个实例都有自己的SGA和buffer cache，每个block都有都有一个实例主控，该实例负责跟踪block变化情况。例如当一个节点发生down机，将发生dynamic resource reconfiguration (动态资源重新配置)。除此之外还有一种情况，主控节点buffer cache resource 大量被访问，为了确定是否需要动态remaster，GCS基于每个实例和每个对象跟踪GCS请求，当发现同一个对象block在一个节点被频繁访问，GCS将动态把所有实例上该对象资源迁移到访问最频繁的节点之中，LMON，LMD和LMS将负责动态remaster。
分析生产交易，有一张流水表高频度插入数据，且监控中可以看到两个节点直接都有在运行。
oracle官方提供了一个诊断脚本DRMDIAG.SQL，通过v$active_session_history可以看到在性能下降的那个时刻发生drm free。
---求阈值
column threshold_in_ms new_value threshold format 999999999.999
select decode(min(threshold_in_ms),null,0,min(threshold_in_ms)) threshold_in_ms
from (select inst_id, to_char(sample_time,'Mondd_hh24mi') minute,
sum(time_waited)/1000 threshold_in_ms
from gv$active_session_history
where event like '%drm freeze%'
group by inst_id,to_char(sample_time,'Mondd_hh24mi')
order by 3 desc)
where rownum <= 10;
--查看发生DRM时间，等待时间和次数
column event format a30 tru
column program format a35 tru
column total_wait_time format 999999999999.999
column avg_time_waited format 999999999999.999
select to_char(sample_time,'Mondd_hh24mi') minute, inst_id, event,
sum(time_waited)/1000 TOTAL_WAIT_TIME , count(*) WAITS,
avg(time_waited)/1000 AVG_TIME_WAITED
from gv$active_session_history
where event like '%drm freeze%'
group by to_char(sample_time,'Mondd_hh24mi'), inst_id, event
having sum(time_waited)/1000 > &&threshold
order by 1,2;
通过内部参数关闭DRM，需要重新启动数据库
alter system set " _gc_policy_time"=0 scope=spfile sid='*';
alter system set "_gc_undo_affinity"=false scope=spfile sid='*';
总结：在交易型生产系统中，应用服务器通过SCAN IP连接数据库，如果对某个流水表高频度进行操作，建议关闭DRM
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/354732/viewspace-2146330/，如需转载，请注明出处，否则将追究法律责任。