RAC Cache Fusion 原理理解

Posted 2020-06-17

cache fusion  .   grd  .  drm   .   gcs  .   ges


cache fusion 
1.RAC是一个数据库执行在多个实例上。通过DLM(Distributed Lock Management):分布式锁管理器 来解决并发问题。RAC各个节点间的共享资源，为了保证每一个节点訪问数据的一致性。所以须要使用DLM来协调各个实例间的资源竞争訪问。 这个DLM在RAC中就叫Cache Fusion.


2.在cache Fusion 中，每一个数据块都被映射成Cache Fusion资源。该资源实际上就是一个数据结构，资源的名称就是数据块地址，数据块请求过程：先将数据块地址X转换成Cache Fusion资源名称，然后把这个cache fusion 资源请求提交给DLM，DLM进行Global Lock 的申请。释放活动，仅仅要进程获得了PCM Lock才干继续下一步，即：实例须要获得数据块的使用权。

（先将地址转换成cache fusion资源---->把该资源提交给DLM---->获得该资源的使用权）


GRD
1.GRD(Global Resource Directory) 能够看做是一个内部数据库，记录每一个数据块在集群间的分布图，位于每一个实例SGA中。每一个实例SGA中的GRD汇成了一个完整的GRD。在RAC的master node上记录了该资源在全部节点上的使用信息。而每一个节点的使用信息记录在本节点上。


DRM
1.DRM(Dynamic Resource Management),当一个非MASTER节点的资源被频繁訪问时，通过DRM就可将该节点提升为master节点，将节点remaster成master节点。
2.通过使用DRM造成的问题：
实验。。。。。


GCS
1.GCS(Global cache service)全局缓存服务：要和cache fusion结合在一起来理解。

全局缓存要设计到数据块。

全局缓存服务负责维护全局缓存存储区内的缓存一致性，确保一个实例在不论什么时刻要改动一个数据块时，都可获得一个全局锁资源，从而避免还有一个实例同一时候改动该块的可能性。进行改动的实例将拥有块的当前版本号（包含已提交的和未提交的事务）以及块的前像（post image）。

假设还有一个实例也请求该块，那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本号是什么，以及块处于何种模式。LMS进程是全局缓存服务的关键组成部分。
2.LMSn(LOCK MANAGER SERCIVE) 负责数据块在实例间的传递，通过參数GCS_SERCER_PROCESSES来控制，缺省值是2个。取值范围为0-20.


GES
1.GES(Global enqueue service)全局队列服务：主要负责维护字典缓存和库缓存内的一致性。字典缓存是实例的SGA内所存储的对数据字典信息的缓存，用于快速訪问。因为该字典信息存储在内存中，因而在某个节点上对字典进行的改动(如DDL)必须马上被传播至全部节点上的字典缓存。GES负责处理上述情况，并消除实例间出现的差异。处于相同的原因，为了分析影响这些对象的SQL语句，数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进行维护，而全局队列服务必须确保请求訪问相同对象的多个实例间不会出现死锁。LMON、LCK和LMD进程联合工作来实现全局队列服务的功能。GES是除了数据块本身的维护和管理（由GCS完毕）之外。在RAC环境中调节节点间其它资源的重要服务。
2.LMON
各个实例的LMON进程定期通信。以检查集群中各个节点的健康状态。当某个节点出现问题时，负责集群重构。GRD恢复等操作，它提供的服务叫做：Cluster Group Services(CGS)。

LMON 主要借助两种心跳机制来完毕健康检查：
1-节点间的网络心跳（Network Heartbeat）:能够想象成节点定时发送ping包检查节点状态，假设能在规定时间内收到回应，就觉得状态正常。
2-通过控制文件的磁盘心跳（Controlfile Heartbeat）；每一个节点的CKPT进程每隔3秒更新一次控制文件一个数据块，这个数据块叫做Checkpoint Progress Record,控制文件是共享的，所以实例间能够相互检查对方是否及时更新来推断。


3.LCK
这个进程负责Non-cache fusion资源的同步訪问。每一个实例有一个LCK进程。
4.LMD
这个进程负责的是Global Enqueue Service(GES)。详细来说，这个进程负责在多个实例之间协调对数据块的訪问顺序。保证数据的一致性訪问。它和LMSn进程的GCS服务还有GRD共同构成RAC最核心的功能CACHE fusion。

Global Resource Directory由Global Cache Service 来管理
记录资源的模式、资源的角色、block在实例中的状态、在各个活动的节点公布资源的master、在必要的时候又一次公布master（比如实例的启动和关闭）


Global Cache Service
1、资源模式。三种
null(默认的)
share(s)(查询)
exclusive(x)(能够改变block的内容。其它的实例就是null mode)。
2、资源角色，两种
Local：第一次请求资源的初试模式；仅仅有一个实例能够有这个block的dirty copy
global：当一个block在多个实例中变dirty时。local就变成了Global Block仅仅能由Global Cache Service写到磁盘中


Cache Fusion Block的传输
比如：有ABCD四个节点，Global Cache Service：GCS
1.Read with no transfer
假设c节点须要向共享磁盘文件上读一个block，那么它向Global Cache Service发送请求，这个时候请求被定向到节点D，D是这个BLOCK的MASTER（每一个资源都有master）。GCS把资源授权为Share Mode和local Role，在文件夹中记录下了他的状态（文件夹在节点D），然后通知C，C把这个资源从null改成share。

C開始I/O,如今C有了这个BLOCK以SHARE模式从磁盘文件读取。

2.Read to write transfer
B也要这个block，并且不仅是读。并且还要改变它的内容。

B向D（这个block的master）的GCS发出请求，GCS向C发出请求。要求C把这个block给B。C把block给B。B收到后，告诉GCS，如今B能够改动这个block了。

3.Write to write transfer
A向D节点的GCS发出请求。GCS告诉B节点放弃他的Exclusive锁，而且把当前的Image传到A，假设这个请求没有完毕，就会放到GCS的队列里。B把这个block传到A。这个时候要写Log,强制lg flush。把模式变成null。

发送到A而且告诉它这个Exclusive的资源能够用了。A收到这个block的image。会通知GCS而且告诉它block的status是exclusive，这个时候，B不能对这个block做操作。尽管在它的buffer cache中。它还有这个block的copy。

4.Write to read transfer
C要读这个block，先向D(Master)发出请求，GCS要求A把它传输到C，A接受到请求完毕它的工作。这可能会在A写LOG和LOG FLUSH 在发送这个block之前。A会把它的Exclusive锁减少到share模式。C把从A收到的block的SCN取出来。建设成一个资源Assumption信息为GCS更新Global Resource Directory。

通过设置參数gc_files_to_locks。能够关闭cache fusion。
cache resource 在一个节点上不在须要继续master，dynamic Remastering能把它移动到不同的节点。


问题：
1.在全部实例都未读取该块，而第一个实例读取时。是怎么加的锁，加的什么锁？假设此时有还有一个实例也要读这个块，差点儿是同一时候的，那么oracle怎样来仲裁，怎样让当中一个读取。而还有一个再从前者的缓存中通过cache来得到？
2.假设一个块已经被其它实例读入。那么本实例怎样推断它的存在？
3.假设某个实例改变了这个数据块，是否会将改变传递到其它实例，或者说其它实例是否会知道并又一次更新状态？
4.假设一个实例要swap out某个块，而同一时候其它实例也有这个块的缓存，改动过的和未改动过的，本实例改动的和其它实例改动的。怎样操作？truncate一张表，drop一张表和单实例有何不同?

5.应该怎样设计应用，以使rac真正发挥作用，而不是引入竞争。导致系统被削弱？
6.RAC下锁的实现。

锁是在各实例的SGA中保留的资源，通常被用于控制对数据库块的訪问。每一个实例一般会保留或控制一定数量与块范围相关的锁。

当一个实例请求一个块时，该块必须获得一个锁，而且锁必须来自当前控制这些锁的实例。也就是锁被分布在不同的实例上。

而要获得特定的锁要从不同的实例上去获得。

可是从这个过程来看这些锁不是固定在某个实例上的，而是依据锁的请求频率会被调整到使用最频繁的实例上，从而提高效率。




1.一个A实例读取块须要向GCS发送请求，该块的master实例B会通过GCS将资源授权为SHARE MODE 。在master节点B记录状态，之后在通知请求的节点A由null改成share,開始I/O，
所以此时请求资源的节点A加的是 SHARE 锁。假设有还有一个实例C要读取该块，通知master节点B的GCS发出，要求A把block给C。
2.一个实例请求块的时候须要訪问该块的master节点，此时该块的master节点就会通过GCS跟踪拥有该块的实例，该块的版本号是什么。还有该块处于什么模式。在master节点中都有记录。
3.假设一个实例改变了数据块，GES的LMON进程中的磁盘心跳机制起作用，每一个节点的CKPT进程每隔3秒更新控制文件的一个数据块，控制文件是共享的，来检查是否及时更新。

4.查看master节点的该块的当前状态。假设改动的块为写LOG和LOG FLUSH之前。就会把当前节点拥有的块由exclusive锁减少到share锁。
5.通过GCS和GES来实现。


參考博客：http://www.cnblogs.com/sopost/archive/2013/03/14/2960490.html
 http://blog.csdn.net/tianlesoftware/article/details/5353087
 《 大话Oracle RAC》