ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

[转载] DRM 简介

2021-11-22 13:58:15  阅读:185  来源: 互联网

标签:buffer 简介 数据库 实例 DRM 步骤 master 转载


原文地址 : 

DRM 简介 (oracle.com)

首先,我们对和DRM 相关的一些概念进行介绍。
Buffer: 对于RAC 数据库,当一个数据块被读入到buffer cache后,我们就称其为buffer , cache fusion 会将这个buffer作为resource来管理。

Master:在RAC 数据库的世界里,每一个resource都会有一个master实例,这个master实例会在shared pool 中(例如:gcs resource 和ges resource 部分)分配一些空间来存放和这个资源相关的信息,例如:哪一个实例拥有了这个buffer的最新版本,哪一个实例拥有了这个buffer的什么级别的lock等等。并且,负责维护和这个资源的状态。

接下来,我们对RAC 环境中,访问一个buffer的过程进行简单的描述。我们以一个4节点的RAC 数据库为例。注意,我们只会列出比较典型的一种情况,不会把所有可能的情况都一一列出,而且只是把步骤进行了简单的介绍。

 

 

步骤1:实例3需要以X(exclusive)方式访问buffer1, 向master实例(1) 发出了请求。
步骤2:master实例(1)发现实例2 以X方式持有buffer1,之后通知实例2释放X lock,并把buffer1发送给实例3。
步骤3: 实例2释放X lock,并把最新版本的buffer1发送给实例3。
步骤4:实例3获得buffer1, 并通知master 实例(1)更新资源buffer1的最新状态。

从上面的步骤,我们不难看出,在RAC 数据库中,当我们访问一个buffer的时候,最多会有3个实例参与其中,master实例,holder(持有者)实例 和requestor(申请者) 实例。2种数据传输会出现,message:用于和lock相关的信息传输,data:用于传输buffer。同时,根据上面的步骤我们也自然会想到,如果master和requestor在同一个实例上,那么就可以减少实例之间message的传输并且访问的代码路径(code path)会更短,从而提高性能,但是每个buffer在被读取到buffer cache时,master节点的选择是随机的。基于这种考虑, oracle从10g开始,推出了一个新特性DRM(Dynamic Resource management)。


DRM的主要功能是,根据一段时间内(默认10分钟),每个实例,对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式,来决定数据库对象对应的buffer应该被mastering 到哪一个实例。在指定时间内,如果某一个实例访问某个数据库对象次数高于其他实例一定倍数(默认50倍),则oracle 会把这个对象所有的buffer的master信息,转移到对应实例(注意:不是转移buffer)。当然,转移的过程是渐进式的。当oracle 决定将一个buffer的master实例确定到本地实例后,会对这个buffer上加上affinity lock,来实现快速的访问。这也是我们经常提到的object affinity 的由来。

接下来,我们对DRM的基本步骤进行介绍。
1. Oracle停止所有在需要进行remastering的buffer上的操作。注意:DRM是渐进的,也就是说以windows 为单位,每次对一部分的buffer 进行remastering 操作。
2. Lmon 通知所有实例,准备进行remastering
3. 在旧的master实例清除对应buffer的master信息
4. 将master信息传递给新的master实例
5. 在新的master实例构建资源的最新状态
6. 结束,并释放所有之前所有步骤占用的资源。

然后,我们对DRM相关的一些参数进行简单的介绍。
_gc_policy_time :单位为分钟,控制DRM统计实例访问buffer次数的时间间隔,默认为是10分钟。
_gc_affinity_ratio:控制进行remastering所需要达到的最小比例(阀值),默认为50。也就是说,如果某个实例在10分钟(_gc_policy_time)之内,访问某个数据库对象的次数大于其他所有实例50倍时(注意:是50倍,而不是50次),对该数据库对象的buffer进行remastering。

注意:请不要修改以上参数的值,除非您很清楚自己在做什么,或者是根据oracle 工程师的建议。

最后,如果您遇到了和DRM相关的问题,建议您查看以下的信息。
1. Lmon,lmd,lms和diag进程的 trace file,来确认问题出现在DRM的哪一步和lms,lmon,lmd进程的状态。
2. AWR 和ASH report,确认那些等待事件持续了很长时间,以及lmon,lms 和lmd的状态。
3. 参照note 1492990.1 获取 DMR 诊断脚本输出。

希望以上的介绍对理解DRM有些帮助。

 

标签:buffer,简介,数据库,实例,DRM,步骤,master,转载
来源: https://blog.csdn.net/xxzhaobb/article/details/121470099

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有