Oracle RAC Cache Fusion 系列十七：Oracle RAC DRM

Posted 2022-12-13 woqutechteam

根据前面系列的文章的解释，我们知道PCM资源的Master节点是通过hash算法得出。那么在一个多节点的RAC集群中，数据块请求节点和存放它的相关锁元素信息节点有很大概率是不相同的。这就意味着用户对资源的请求会存在很多的2或3次回路，从而造成很多的消息通信增加私网的负载进而影响影响数据库的性能。为了缓解这种性能影响，Oracle使用资源的remaster来减少资源的跨节点请求。针对某一个数据库对象的的访问次数和方式，来决定数据库对象对应的buffer应该被mastering 到哪一个实例。这里的“访问”更明确地说是请求BL锁。

其实早在9i版本，Oracle就意识到这个问题并开始引入了我们一般都不会注意到的隐含参数包括：_lm_dynamic_remastering，_lm_dynamic_lms，_lm_file_affinity，_lm_dynamic_load 可以通过SQL语句查看参数描述：

SELECT KSPPINM  AS "hidden parameter",
       KSPPSTVL AS "value",
       KSPPDESC "description"
  FROM X$KSPPI
  JOIN X$KSPPCV
 USING (INDX)
 WHERE KSPPINM LIKE '\\_%' ESCAPE '\\'
   AND KSPPINM LIKE '_lm_%'
 ORDER BY KSPPINM;

---

10.1版本开始Oracle正式支持file affinity。10.2版本Oracle进行了优化将file affinity进行细化为object affinity及undo affinity，并记录系统的负载信息（默认由参数_lm_lhupd_interval控制）。file affinity由下面两个参数来控制：

_gc_policy_time ：单位为分钟，控制DRM统计实例访问buffer次数的时间间隔，默认为是10分钟。

_gc_affinity_ratio：控制进行remastering所需要达到的最小比例（阀值），默认为50。也就是说，如果某个实例在10分钟。

object affinity：根据一段时间内（默认10分钟），如果某一个实例访问某个数据库对象次数高于其他实例一定倍数（默认50倍），则oracle 会把这个对象所有的buffer的master信息，转移到对应实例（注意：不是转移buffer）。当oracle 决定将一个buffer的master实例确定到本地实例后，会对这个buffer上加上affinity lock，来实现快速的访问。

DRM过程会存在如下几个阶段：

1.Quiescs：Lmon通知所有实例，准备进行remastering。
2.Freeze：Oracle停止所有在需要进行remastering的buffer上的操作。
3.Cleanup：在旧的master实例清除对应buffer的master信息。
4.Rebuild：将master信息传递给新的master实例,在新的master实例构建资源的最新状态。
5.Unfreeze：结束，并释放所有之前所有步骤占用的资源。

注意：DRM是渐进的，也就是说以windows为单位，每次对一部分的buffer 进行remastering操作。

从这个流程我其实就知道DRM虽好但是存在的问题也很明显，即在DRM过程中对涉及的数据块的请求都将被阻塞。因此Oracle一直在不断的优化DRM动作，希望能够减少DRM带来的影响。11g版本减少DRM给系统带来的影响Oracle进行了如下几处优化：

1.read-mostly locking（读多写少）：简单的说就是，对于某个对象，比如读非常多，所有结点都会持有一个锁，减少了共享锁申请操作。而当需要写操作时，需申请排它锁时，在每个结点上都申请一个”anti-lock”锁，可以理解为”反锁”,然后再cache fusion。

2.reader bypass（写少读多）：主要是为读少写多的业务进行的优化。reader bypass同样引入了一种新的锁模式weak X lock（又称xw锁）。可以在S锁没有释放以前，为一个block加上一个xw锁，对这个block进行修改，但是不允许立刻commit，直到所有的的S锁都关闭或者降级到N锁，LMS就会向xw锁的持有者发送一条信息可以进行commit了。

3.Parallel DRM Freeze：在DRM发生的过程中会存在冻结阶段（Freeze）,即所有节点的LMS进程在收到LMON发出的消息后，通知所有节点的LMS进程在结束master信息迁移前不再接受对这些快的新的请求。那么对于一个繁忙的系统这个过程是无法忍受的，因此Oracle引入了并行DRM加快master信息的迁移速度，使用_drm_parallel_freeze参数控制，默认情况下启用。

4.DRM Batch request：批量处理DRM请求使用参数_lm_drm_batch_time控制，默认为10s。

5.DRM interval：增大DRM触发时间间隔，针对连续的DRM动作时间间隔至少为120s，由参数_lm_drm_min_interval控制。

6.Read Mostly数据固化：早先版本针对DRM的ReadMostly系统统计信息会随着实例的重启而被重置，为此从11.2.0.3版本开始，默认支持对read mostly的数据进行固化（通过_gc_persistent_read_mostly来实现)。

7.drm hiload：在数据库负载很高的情况下，会暂时禁用DRM，数据库负载下降以后又重新启用DRM,由参数_lm_drm_hiload_percentage和_lm_drm_lowload_percentage参数控制默认为200。

  Undo and affinity  

回滚段的Mastering和其它段不同，因为RAC环境中的每个实例均有各自自己的undo表空间。回滚段的remastering是不会因为另外一个节点对于回滚段有大量读取而发生的。只有在某个实例失效，为了进行实例恢复的需要，集群中负责进行实例恢复的其他实例会暂时的成为这些回滚段的master，然后进行实例的恢复动作。undo的remaster是由参数_gc_undo_affinity控制。

12C版本Oracle继续对DRM进行优化，Oracle在进行资源冻结的时候并非冻结所有资源。而是将资源分解为多个分区，以只冻结资源分区的这种方式极大地减少DRM相关等待的影响。LMON一次只冻结一个资源分区。第一个分区中的资源被冻结，完成资源重新创建任务，并解冻该资源分区。然后冻结下一个资源分区并继续，直到重新创建所有资源。除此之外12c还引入了很多相关的Latch机制（gcsaffinity object freelist latch）和统计信息链表（affinity statsobjects freelist ） ，Object的affinity stats数据是由lck0进程来进行维持，还引入了可以由用户自定义read mostly实例的参数（_read_mostly_instance ,_read_mostly_instance_qa_control）。 

Parameter：_high_priority_processes

Value：LMS*|VKTM|LM*|LCK0|GCR*|DIAG