在单实例中，进程要想修改数据块，必须在数据块的当前版本（current copy）上进行修改.rac环境也一样
在单实例中，进程要想修改数据块，必须在数据块的当前版本（current copy）上进行修改
rac环境也一样
这便涉及到一系列问题：
如何获得数据块的版本在集群节点间的分布图？
如何知道哪个节点拥有的是当前版本？
如何完成传递过程？
这一系列问题的解决依靠内存融合技术（cache fusion）
cache fusion通过高速的private interconnect，在实例间进行数据块传递
这是rac最核心的工作机制，他把所有实例的sga虚拟成一个大的sga区
每当不同的实例请求相同的数据块，这个数据块就需要在实例间进行传递
在oracle 7的ops中，这种传递是通过磁盘完成的，也叫“disk-based ping”
也就是第1个实例必须先把这个数据块写回磁盘，然后第2个实例再从磁盘上读取这个数据块
这种依靠磁盘来完成数据传递极大影响系统性能
在oracle 8i引入“net-based ping”通过private interconnect来传递数据块
但是8i只能传递没有修改过的数据块，对于“脏块”还是要通过磁盘来传递，，这一点和ops一样
在oracle 9i的cache fusion，所有的数据块，无论修改的或者没有修改的，都可以通过private interconnect传递
系统系能得到极大的改善
在cache fusion中，每个数据块都会被映射成一个cache fusion 资源，或者说是一个pcm 资源
pcm资源实际上是一个数据结构，资源的名称就是dba(数据块地址)
每个进程对数据的请求都是分步完成：
① 把dba转换成pcm资源名称
② 把这个pcm资源请求提交给dlm（分布式锁管理器）
③ dlm进行global lock的申请、释放活动，只有进程获得了pcm lock，才能继续下一步
也就是实例首先要获得数据块的使用权
整个cache fusion有两个服务组成：gcs和ges
⑴ gcs服务负责数据块在实例间的传递
由后台进程lmsn完成
⑵ ges服务负责锁管理
在多个实例之间协调对数据块的访问顺序，保证数据的一致性访问
由后台进程lmd完成