RAC Cache Fusion 原理理解
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》
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》