本篇内容主要讲解“甲骨文DRM原理是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“甲骨文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． 甲骨文停止所有在需要进行重设主控的缓冲区上的操作。注意:DRM是渐进的,也就是说以windows为单位,每次对一部分的缓冲进行重设主控操作
2。Lmon通知所有实例,准备进行重设主控
3。在旧的主实例清除对应的缓冲区的主信息
4。将主信息传递给新主人的实例
5。在新主人的实例构建资源的最新状态
6。结束,并释放所有之前所有步骤占用的资源
然后,我们对DRM相关的一些参数进行简单的介绍。
_gc_policy_time:单位为分钟,控制DRM统计实例访问缓冲次数的时间间隔,默认为是10分钟
_gc_affinity_ratio:控制进行重设主控所需要达到的最小比例(阀值),默认为50
也就是说,如果某个实例在10分钟(_gc_policy_time)之内,访问某个数据库对象的次数大于其他所有实例50倍时(注意:是50倍,而不是50次)
对该数据库对象的缓冲进行重设主控
注意:请不要轻易修改以上参数的值,除非有技术支持
最后,如果您遇到了和DRM相关的问题,建议您查看以下的信息。
1。Lmon lmd, lms和诊断接头进程的跟踪文件,来确认问题出现在DRM的哪一步和lms, Lmon, lmd进程的状态。
2。的心田和灰报告,确认那些等待事件持续了很长时间,以及lmon, lms和lmd的状态。
3。参照注意1492990.1获取DMR诊断脚本输出。
