C/C++教程

Oracle DRM的坑与填坑

本文主要是介绍Oracle DRM的坑与填坑,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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 60

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的历史对象记录:

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。

 

这篇关于Oracle DRM的坑与填坑的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!