标签：buffer 填坑 实例 DRM 关闭 Oracle master gc
Oracle DRM的坑与填坑
梁铭图 2020-02-27 12:14:00作者介绍
梁铭图，新炬网络首席架构师，十多年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有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等等。并且，负责维护和这个资源的状态。
DRM的基本步骤进行介绍
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是否发生切换和切换的实例：
column objname format a120 truselect o.name || ' - '|| o.subname objname, o.type#, h.*from v$gcspfmaster_info h, obj$ o where h.data_object_id=o.dataobj# order by data_object_id;
检查发生DRM的统计：
set heading offset lines 60select '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的历史对象记录：
select * from gv$policy_history order by event_date;
在线调整DRM配置参数：
_lm_drm_disable0:启动所用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等等。并且，负责维护和这个资源的状态。
DRM的基本步骤进行介绍
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。
标签：buffer,填坑,实例,DRM,关闭,Oracle,master,gc 来源： https://www.cnblogs.com/yaoyangding/p/15750219.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。