Oracle DRM的坑与填坑

作者介绍

梁铭图，新炬网络首席架构师，十多年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有Oracle OCM、Togaf企业架构师（鉴定级）、IBM CATE等认证，曾获dbaplus年度MVP以及华为云MVP等荣誉，并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。

DRM的简介

DRM是oracle从10g开始，推出了一个新特性，主要是管理RAC环境下的动态内存资源管理。

Buffer: 对于RAC 数据库，当一个数据块被读入到buffer cache后，我们就称其为buffer , cache fusion 会将这个buffer作为resource来管理。

Master：在RAC 数据库的世界里，每一个resource都会有一个master实例，这个master实例会在shared pool 中（例如：gcs resource 和ges resource 部分）分配一些空间来存放和这个资源相关的信息。

例如：哪一个实例拥有了这个buffer的最新版本，哪一个实例拥有了这个buffer的什么级别的lock等等。并且，负责维护和这个资源的状态。

1． Oracle停止所有在需要进行remastering的buffer上的操作。注意：DRM是渐进的，也就是说以windows 为单位，每次对一部分的buffer 进行remastering 操作

2． Lmon 通知所有实例，准备进行remastering

3． 在旧的master实例清除对应buffer的master信息

4． 将master信息传递给新的master实例

5． 在新的master实例构建资源的最新状态

6． 结束，并释放所有之前所有步骤占用的资源

与DRM相关的参数

DRM相关的一些参数进行简单的介绍：

_lm_drm_disable

0:启动所用DRM功能

4:关闭read mostly功能

5:4+关闭object affinity功能

7:5+关闭undo affinity功能(关闭所有DRM)

_gc_policy_time ：单位为分钟，控制DRM统计实例访问buffer次数的时间间隔，默认为是10分钟

_gc_affinity_ratio：控制进行remastering所需要达到的最小比例（阀值），默认为50

也就是说，如果某个实例在10分钟（_gc_policy_time）之内，访问某个数据库对象的次数大于其他所有实例50倍时(注意：是50倍，而不是50次)对该数据库对象的buffer进行remastering。

一次Oracle DRM折腾记录

某客户上线一套新系统，数据库使用11g RAC。

在测试阶段，客户反馈新系统主要用于批量结算任务，但运行DML语句的时候会比较慢， 希望进行优化。

通过AWR和ASH报告发现，主要的等待事件是gc current grant 2-way等待事件，占db time的30%左右，对个别会话进行10046 trace，确实存在大量这类等待，并且等待时间也是占总时间30%左右。 

对系统进行了一系列检查，均未发现异常问题，最后检查参数配置发现已经设置关闭了DRM功能，尝试重新开启DRM功能并重启实例进行测试，gc事件消失，DML语句操作时间减少30%。

由于开启DRM可能触发一些性能问题，为了保险起见再次询问了客户是否只是运行批量任 务，得到客户确认并对测试结果也比较满意。

然而在系统上线后出现了事情了，原来还有一个交易模块需要对接互联网公司并且对业务实 时性要求非常高(处理时间3秒超时)，每次在结算批量时间就会出现超时问题，并且问题已经持续一周时间客户非常重视。

现场同事对log file大小和路径进行了调整，批量业务也迁移至节点2，问题已有所缓解，但实时业务处理时间还是比较长，仍存在部分的超时。

经过对现场环境检查，整理出以下可疑点:

1．主要等待事件是log file sync。

2．实时dml语句是insert，每分钟执行约1200次。

3．io服务时间有增加，但在正常的范围。

4．存在drm remaster操作但统计时间很短。

5．应用厂家反馈，超时会话日志显示等待的时间耗费在commit过程。

对上述疑点进行梳理后，整理出以下分析思路:

1．自适应写日志同步方式，这是11g的新特性，关闭该特性能缓解log file sync等待事件。

2．IO写性能分析，commit阶段除了oracle自身需要同步等待外，还存在写日志IO操作，因此trace一下LGWR进程监控一下IO写入性能是否正常。

3．由于发生DRM remaster过程会出现短暂的挂起，对于时间敏感的应用会出现较大的影响。

整理好思路后，再次检查了lgwr和lms，lmon，lmd后台进程相关日志，发现问题时间段 lgwr模式未发生变化，drm相关进程出现了remaster操作信息。

通过上面的检查，初步认为drm导致超时的可能性比较高。

在客户会议中，在与存储厂家，开发商，对相关功能和疑点进行解析和答疑后，客户也认可该分析思路。

1．监控IO性能，trace LGWR。

2．关闭DRM。

3．关闭自适应日志同步方式。

在实施阶段，有一段批量操作可以重复进行，因此决定进行3次测试并对比调整前后的效果。

测试1：按原有配置不做调整，测试中发现部分处理时间超过1到2秒钟，处理时间存在突变，问题非常明显。(检查lgwr写操作时间最大增加了30倍，但小于3ms属于正常范围; DRM发生remaster)

测试2：动态关闭DRM功能，测试中发现处理时间变得平稳，处理时间小于500ms，处理时间处于可接受范围，并且不存在处理时间突变问题(图形显示尖端)。

测试3：在测试2的基础上继续关闭自适应功能，测试中发现处理时间依然平稳，处理时间小于500ms，处理时间处于可接受范围，但存在处理时间突变问题。

最后，恢复自适应功能，并完成后续批量操作，效果明显，正常处理时间100ms，结算批量处理时间维持在500ms。结算批量操作时间有所增加，但客户可以接受。

问题至此似乎得到解决。

然而几周后...电话又响起了...

这次又是gc current grant 2-way，客户重启了运行结算批量的实例后，结算批量时间增加了不少，导致结算缓慢，等待事件又是gc current grant 2-way，感觉又回到了原点。

在电话沟通和收集资料后我们找到了一个新的思路：通过oradebug lkdebug -m pkey DATA_OBJECT_ID命令可以手动将DRM资源固定在某个实例，经过测试效果明显。

分析其原因主要是因为重启前经过多次批量操作后资源已经remaster到结算实例，动态关闭DRM功能后，这些DRM资源依然保留在结算实例上，所以对批量结算影响不大。

当实例重启后由于DRM需要重新分配，这时就会出现大量gc等待影响DML的性能。

这次基本可以说走了一遍了DRM的坑。

小结

1．RAC环境中，如果业务只在单个实例运行，另一个实例作为热备，开启DRM确实可以有效减少gc 2-way事件并提高批量速度，由于业务固定运行在一个实例，基本不会产生副作用。

2．对实时性要求较高的系统，关闭DRM是最好的策略，能避免出现诡异的挂起和缓慢问题。

3．关闭DRM后，若对个别对象需要大批量的更新操作，可以通过oradebug lkdebug - m pkey DATA_OBJECT_ID命令指定实例，但该操作其实存在较大的局限性，如ddl操作导致DATA_OBJECT_ID变化和实例重启后需要重新执行指定。

附：DRM相关检查脚本：

检查对象pkey是否发生切换和切换的实例：

from v$gcspfmaster_info h, obj$ o where h.data_object_id=o.dataobj# order by data_object_id;

检查发生DRM的统计：

select 'Instance: '||inst_id inst, 'Remaster Ops: '||remaster_ops rops,'Remaster Time: '||remaster_time rtime, 'Remastered Objects: '||remastered_objects robjs, 'Quiesce Time: '||quiesce_time qtime, 'Freeze Time: '||freeze_time ftime, 'Cleanup Time: '||cleanup_time ctime, 'Replay Time: '||replay_time rptime, 'Fixwrite Time: '||fixwrite_time fwtime, 'Sync Time: '||sync_time stime, 'Resources Cleaned: '||resources_cleaned rclean, 'Replayed Locks Sent: '||replayed_locks_sent rlockss, 'Replayed Locks Received: '||replayed_locks_received rlocksr, 'Current Objects: '||current_objects

from gv$dynamic_remaster_stats

order by 1;

检查发生DRM的历史对象记录：

在线调整DRM配置参数：

4:关闭read mostly功能

5:4+关闭object affinity功能

7:5+关闭undo affinity功能(关闭所有DRM)

select owner, object_name, object_type, object_id, data_object_id

from dba_objects

where object_id in(select DATA_OBJECT_ID from V$GCSPFMASTER_INFO) and object_id <> data_object_id;

作者介绍

梁铭图，新炬网络首席架构师，十多年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有Oracle OCM、Togaf企业架构师（鉴定级）、IBM CATE等认证，曾获dbaplus年度MVP以及华为云MVP等荣誉，并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。

DRM的简介

DRM是oracle从10g开始，推出了一个新特性，主要是管理RAC环境下的动态内存资源管理。

Buffer: 对于RAC 数据库，当一个数据块被读入到buffer cache后，我们就称其为buffer , cache fusion 会将这个buffer作为resource来管理。

Master：在RAC 数据库的世界里，每一个resource都会有一个master实例，这个master实例会在shared pool 中（例如：gcs resource 和ges resource 部分）分配一些空间来存放和这个资源相关的信息。

例如：哪一个实例拥有了这个buffer的最新版本，哪一个实例拥有了这个buffer的什么级别的lock等等。并且，负责维护和这个资源的状态。

1． Oracle停止所有在需要进行remastering的buffer上的操作。注意：DRM是渐进的，也就是说以windows 为单位，每次对一部分的buffer 进行remastering 操作

2． Lmon 通知所有实例，准备进行remastering

3． 在旧的master实例清除对应buffer的master信息

4． 将master信息传递给新的master实例

5． 在新的master实例构建资源的最新状态

6． 结束，并释放所有之前所有步骤占用的资源

与DRM相关的参数

DRM相关的一些参数进行简单的介绍：

_lm_drm_disable

0:启动所用DRM功能

4:关闭read mostly功能

5:4+关闭object affinity功能

7:5+关闭undo affinity功能(关闭所有DRM)

_gc_policy_time ：单位为分钟，控制DRM统计实例访问buffer次数的时间间隔，默认为是10分钟

_gc_affinity_ratio：控制进行remastering所需要达到的最小比例（阀值），默认为50

也就是说，如果某个实例在10分钟（_gc_policy_time）之内，访问某个数据库对象的次数大于其他所有实例50倍时(注意：是50倍，而不是50次)对该数据库对象的buffer进行remastering。