cache fusion

概念

    简单地说，缓存融合就是把Oracle RAC数据库中所有数据库缓存作为一个共享的数据库缓存，并被RAC中的所有节点共享。它是实现RAC的基本技术。

    缓存融合主要有如下四个功能：

  （1） 提供扩展性的传输。

  （2） 在实例间传输数据库的映射。

  （3） 跟踪资源的当前位置和状态。

  （4） 在每个实例的SGA的目录结构中保存资源信息。

    图中描述了两节点RAC数据库的运行情况。每个节点都运行一个数据库实例，每个实例包含一组Oracle进程和用于缓存的系统全局区（SGA）。除了这些集群中的每个节点都还运行着一组特殊的进程：全局缓存服务进程（Global Cache Service ，GCS）和全局队列服务进程（Global Enqueue Service，GES），GES主要负责维护字典缓存和库缓存内的一致性，GCS主要负责协调不同实例间对数据块的访问，它们通过Global Resource Directory（GRD）来维护和记录每个数据块的状态，使其在群集中的各个节点之间同步和串行处理对数据的访问。同时，每个数据区块又隶属于某一个节点，对于这个数据区块来说，这个节点称为主节点（Master）。为了在服务器之间均衡工作负载，群集中所有服务器都可以成为部分数据块的主节点，GCS 是oracle 用来实施缓存融合的机制。

缓存融合工作原理

    我们知道，Oracle RAC是采用共享磁盘方式实现数据库的群集。群集环境中所有节点共享且并发地对磁盘上的数据库进行更新，另外还要额外地需要同其它节点进行同步和串行机制，以避免两个或多个节点同时更新同一数据页上的记录，那么Oracle RAC是如何利用缓存融合处理数据同步的？下面通过几种情况模拟分析下缓存的同步原理。
   （1） 节点A读取一个全新的数据块，该数据块没有被任何节点读入
     ①节点A的请求发给GCS，GCS把这个请求转发给这个数据块的主节点，这里假定是节点B。因为这个数据块没有在任何节点的内存中，GCS标记这个数据块状态为S（shared，共享状态），并记录到GRD中。
     ②接着B告诉节点A状态修改了，准备工作都完成了。然后节点A记录共享状态在自己的实例中，并读入该数据块。这时，节点A持有了该数据块，并在GRD中进行记录，标记持有该数据块。此时，整个过程发生了一次IO操作。

  （2） 节点C要修改刚才节点A读入的数据块，这里假定节点A刚才读入的数据块SCN是100。
    ①节点C找到该数据块的主节点，也就是节点B，要求能加一个X标记（exclusive，独占状态），表明要修改数据。但是这个数据块可能已经存在于多个节点的实例中，每个实例都有个S标记。
    ②GCS会告诉所有持有该数据块的实例，把状态S标记转换为N标记（null，空状态）。
    ③最后一个从S标记转换为N标记的实例把数据块发送到需要对其进行修改的节点如节点C上。
    ④这时节点C的实例就可以对该数据块加上X标记，并通知该数据块的主节点，也就是节点B的GCS，GCS将最新的标记与位置记录到GRD，并关闭以前节点的资源记录。这时节点C就可以修改该数据块了，假定把SCN从100修改成了101，这个时候磁盘上的数据块SCN还是100，整个过程是通过内部互联进行数据交换，没有磁盘IO产生。

   （3） 节点D也要修改该数据块
    ①与节点C修改该数据块类似，节点D也会找到该数据块的主节点，也就是节点B，要求加一个X（exclusive，独占状态）的锁，表示要修改该数据块。
    ②这时GCS会告诉上一次修改成功的节点C，放弃它加上的X标记，因为别的节点也要修改这个数据块。
    ③节点C会确保这个数据块的改变，已经记入联机日志中，然后转换X标记为N标记，并把这个数据块拷贝到节点D。
    ④节点D加上X标记，并通知该数据块的主节点，也就是节点B的GCS，GCS将最新的标记与位置揭露到GRD，并关闭以前节点上的资源记录。这时节点D就可以修改该数据块了，假定把该数据块的SCN从101又修改成102，但是磁盘的数据块上的SCN还是100。可以发现RAC在这个过程中，也没有任何磁盘操作，同样是通过内部互联来完成的。

    （4） 节点A要重新读取该数据块
     ①节点A还是一样，首先找到该数据块的主节点，也就是节点B，希望能读取最新的数据块，也就是SCN为102的内容。
     ②GCS根据GRD得知最新的数据块在节点D上，于是GCS通知节点D。节点D需要确保刚才修改过的数据块已经记录在联机日志中，如果已经确定记录过，则把原来的X标记转换为S标记。
     ③节点D拷贝数据块到节点A的实例，这时节点A获得该数据块，并获得S标记。
     ④最后再告诉该数据块的主节点，也就是节点B，GCS记录最新的标记与位置到GRD，这个时候，节点A与节点D同时持有S标记的相同的数据块，数据块的SCN为102，但是磁盘中的数据块SCN还是100，最后如果发生写操作，只要最新的一个节点发生写操作即可，所以该数据块虽然在不同节点、不同实例中发生了多次改变，最终却只有一次写IO操作。

结语

    通过对缓存融合工作原理的介绍，我们就大致知道了缓存融合在RAC环境下是如何工作的，也为我们以后有针对性的对其就行优化提供了依据。

结合后台进程更好理解缓存融合原理：

1、LMSn: Global Cache Service Process。

LMSn进程会维护在Global Resource Directory (GRD)中的数据文件以及每个cached block的状态。LMSn用于在RAC的实例间进行message以及数据块的传输，这个对应的服务也就是GCS(Global Cache Service)，LMS是Cache Fusion的一个重要部分。LMS进程可以说是RAC上最活跃的后台进程，会消耗较多的CPU.一般每个实例会有多个LMS进程，每个Oracle版本的默认的LMS进程数目会有所不同，大部分版本的默认值是：MIN(CPU_COUNT/2, 2))

2、LMD: Global Enqueue Service Daemon。（对应的服务叫GES服务）

LMD 进程主要处理从远程节点发出的资源请求，在多个实例之间协调对数据块的访问顺序，保证数据的一致性访问，大概过程如下：

+ 一个连接发出了global enqueue 请求
+ 这个请求会被发给本节点的LMD0进程
+ 这个前台进程会处于等待状态
+ LMD0会找到这个资源的master节点是谁
+ LMD0会把这个请求发送给master节点
+ 如果需要的话，master节点会增加一个新的master资源
+ 这时从master节点可以获知谁是owner, waiter
+ 当这个资源被grant给requestor后, master节点的LMD0进程会告知requestor节点的LMD0
+ 然后requestor节点的LMD0会通知申请资源的前台进程

GCS服务与GES服务还有GRD共同构成了RAC的Cache Fusion（缓存融合）

缓存融合是RAC内部最复杂的一部分，其中数据块是如何通过private network在实例之间传递，如何控制访问顺序，这些都很复杂，有兴趣的同学可以研究

如上总结LMD主要处理global enqueue 的请求, 而LCK0主要处理本实例的lock.
另外，RAC上的global deadlock 也是由LMD来发现的。

3、LCK0: Instance Enqueue Process。

LCK0进程主要处理非cache fustion的资源请求，比如library 和row cache 请求。

LCK0处理在实例一级的锁：
 Row cache entries
 Library cache entries
 Result cache entries
这些实例级的锁的owner, waiter是LCK0进程。
只要这个实例的锁的owner是LCK0，那么这个实例的任何一个连接都可以使用这种cached的metedata.
如果本地的实例没有拥有这个lock，那么需要申请这个lock，前台进程会等待DFS Lock Handle。
另外，当shared pool出现压力需要释放一些内存来存放新的cursor时，LCK进程会将dictionary cache 的一些内存进行释放。

4、LMON: Global Enqueue Service Monitor。

LMON用于监控整个集群的global enqueues和resources， 而且会执行global enqueue recovery。实例异常终止后，会由LMON来进行GCS内存方面的处理。当一个实例加入或者离开集群后，LMON会对lock和resource进行reconfiguration.也就是说当某个节点出现故障时，LMON负责集群重构，GRD恢复等操作，另外LMON会在不同的实例间进行通讯检查，如果发现对方通讯超时，就会发出节点eviction，所以很多时候节点发生eviction后(ORA-481, ORA-29740等)，我们需要查看LMON的trace来了解eviction的原因。

----------------------------

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 诊断脚本输出。

 

转自：http://blog.csdn.net/wenzhongyan/article/details/7722166

https://www.linuxidc.com/Linux/2014-10/107845.htm

https://blogs.oracle.com/database4cn/drm