共计 2136 个字符，预计需要花费 6 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关如何理解 oracle 11g DRM，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
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． 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 诊断脚本输出。
上述就是丸趣 TV 小编为大家分享的如何理解 oracle 11g DRM 了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
