Cache Fusion （缓存融合）
实际意义上讲就是通过互连网络在集群各个节点内的SGA之间进行块传递，这样做的好处是避免多次将块写入磁盘，再重新读入到其他实例的缓存中。当一个块从磁盘读入RAC环境中的首个实例的sga中，该块会被赋予一个锁资源（区别于行级锁），以让其他实例知道该块正在被使用（或是读），当另一个实例请求该块的操作时，当前实例sga会传递一个块的副本给另一个实例（该块为最新，并未改变）；如果内存中的块已经被改变，但改变尚未提交，会传递一个CR副本，并改变相应的锁资源的级别。从本质上讲，数据库无需多次写回磁盘或从磁盘多次读入相关实例们的sga中，在各实例中的缓存中实现共享和传递，从而避免同步实例缓存所花费的额外i/o。
应用环境：当互连网络速度远远大于磁盘I/O访问速度。
下面是cache fusion中一些概念的介绍
全局缓存服务(GCS):全局缓存（SGA）要涉及到数据块。全局缓存服务负责维护该全局缓冲存储区内的缓存一致性，确保一个实例在任何时刻想修改一个数据块时，都可获得一个全局锁资源，从而避免另一个实例同时修改该块的可能性。进行修改的实例将拥有块的当前CP版本（包括已提交的和未提交的事物）以及块的前象(post image)。如果另一个实例也请求该块，那么GCS要负责跟踪拥有该块的实例、拥有块的版本是什么，以及块处于何种资源模式。LMS进程是全局缓存服务的关键组成部分。（LMS为锁管理服务器进程，为cache fusion请求在实例间的传递服务）
全局队列服务(GES)：主要负责维护字典缓存和库缓存内的一致性。字典缓存是实例的SGA内所存储的对数据字典信息的缓存，用于高速访问。由于该字典信息存储在内存中，因而在某个节点上对字典进行的修改（如DDL)必须立即被传播至所有节点上的字典缓存。GES负责处理上述情况，并消除实例间出现的差异。处于同样的原因，为了分析影响这些对象的SQL语句，数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进行维护，而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。LMON、LCK和LMD进程联合工作来实现全局队列服务的功能。GES是除了数据块本身的维护和管理（由GCS完成）之外，在RAC环境中调节节点间其他资源的重要服务。
1.资源模式：三种
null (默认的)
share(S) (查询)
exclusive(X) (修改block的内容,其它的实例就为null mode)
2.资源角色：两种
local：
第一次请求资源的初试模式;只有一个实例可以有这个block的dirty copy(即磁盘数据块的元数据内容)
global：
当一个Block在多个实例中变dirty时，Local就变成了Global 并最终只能由GCS发送请求写到磁盘中
下面说下 cache fusion block 是如何传输的。
环境：A,B,C,D四个节点，实例D有拥有数据块的MASTER资源权限（每个数据块都拥有一个master）
- Read from no transfer
假设，四个实例的sga从未缓存过该数据块，如果节点C需要向shared data disk 读一个block。 则节点C向GCS发送请求，此时请求被指向节点D（因为节点D是数据块的master），GCS把该块的资源改为share mode（S）和local role 并在D节点的GCS记录状态，并通知，C的GCS把此资源模式从Null->Share C开始I/O读磁盘读取该块。
- Read to Write transfer
B要读写这个数据块，B的GCS向D发出请求，D的GCS向C发出请求，要求C把数据块给B，C把数据块CP传给B，B的GCS修改块的模式Null->Exclusive（X） 且其他节点的模式为->null
- Write to Write transfer
A节点也要修改数据块，A的GCS向D发出请求，D的GCS指向B，如果此时该请求还没完成，则放到GES队列中，B取消修改并把block传给A （此时会强制log flush）b的块模式变为null A收到块后加X锁， 此时，虽然B有块的cp，但不能修改，因为b块模式为null
- Write to Read transfer
C要读block，C的GCS向D发送请求，D指向A，A把该块的锁由X->Share模式，C收到A的块CP 取出SCN,由GCS更新元数据块CP的SCN。
通过设置参数gc_files_to_locks，可以关闭Cache Fusion。
关闭后，则别的节点要读/写数据块时，必须等待占用该块的实例节点提交，写回数据文件中。
注1：当有新的节点添加/崩溃时，原节点的锁资源会重新平衡
注2：当一个节点不再需要master，动态资源控制进程会把他移到请求频率最高的一个节点上