Oracle之缓存融合

CACHE FUSION 原理
为了更深入的了解Oracle的后台进程的工作原理，需要先了解一下 RAC 中多节点对共享数据文件访问的管理是如何进行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 这个重要的概念，要发挥 Cache Fusion 的作用，要有一个前提条件，那就是互联网络的速度要比访问磁盘的速度要快。否则，没有引入 CACHE FUSION 的意义。而事实上，现在 100MB 的互联网都很常见。

什么是 CACHE FUSION？
Cache Fusion 就是通过互联网络（高速的 Private interconnect）在集群内各节点的 SGA 之间进行块传递，这是RAC最核心的工作机制，他把所有实例的SGA虚拟成一个大的SGA区，每当不同的实例请求相同的数据块时，这个数据块就通过 Private interconnect 在实例间进行传递。以避免首先将块推送到磁盘，然后再重新读入其他实例的缓存中这样一种低效的实现方式(OPS 的实现)。当一个块被读入 RAC 环境中某个实例的缓存时，该块会被赋予一个锁资源（与行级锁不同），以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过互联网络直接被传递到另一个实例的 SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个 CR 副本。这就意味着只要可能，数据块无需写回磁盘即可在各实例的缓存之间移动，从而避免了同步多实例的缓存所花费的额外 I/O。很明显，不同的实例缓存的数据可以是不同的，也就是在一个实例要访问特定块之前，而它又从未访问过这个块，那么它要么从其他实例 cache fusion 过来，或者从磁盘中读入。GCS（Global Cache Service，全局内存服务）和 GES（Global EnquenceService，全局队列服务）进程管理使用集群节点之间的数据块同步互联。
这里还是有一些问题需要思考的：
在所有实例都未读取该块，而第一个实例读取时，是怎么加的锁，加的什么锁？如果此时有另一个实例也要读这个块，几乎是同时的，那么 Oracle 如何来仲裁，如何让其中一个读取，而另一个再从前者的缓存中通过 cache 来得到？
如果一个块已经被其他实例读入，那么本实例如何判断它的存在？
如果某个实例改变了这个数据块，是否会将改变传递到其他实例，或者说其他实例是否会知道并重新更新状态？
如果一个实例要 swap out 某个块，而同时其他实例也有这个块的缓存，修改过的和未修改过的，本实例修改的和其他实例修改的，如何操作? truncate 一张表，drop 一张表… 和单实例有何不同？
应该如何设计应用，以使 RAC 真正发挥作用，而不是引入竞争，导致系统被削弱？
RAC 下锁的实现。

锁是在各实例的 SGA 中保留的资源，通常被用于控制对数据库块的访问。每个实例通常会保留或控制一定数量与块范围相关的锁。当一个实例请求一个块时，该块必须获得一个锁，并且锁必须来自当前控制这些锁的实例。也就是锁被分布在不同的实例上。而要获得特定的锁要从不同的实例上去获得。但是从这个过程来看这些锁不是固定在某个实例上的，而是根据锁的请求频率会被调整到使用最频繁的实例上，从而提高效率。要实现这些资源的分配和重分配、控制，这是很耗用资源的。这也决定了 RAC 的应用设计要求比较高。假设某个实例崩溃或者某个实例加入，那么这里要有一个比较长的再分配资源和处理过程。在都正常运行的情况下会重新分配，以更加有效的使用资源；在实例推出或加入时也会重新分配。在 alert 文件中可以看到这些信息。而 Cache Fusion 及其他资源的分配控制，要求有一个快速的互联网络，所以要关注与互联网络上消息相关的度量，以测试互联网络的通信量和相应时间。对于前面的一些问题，可以结合另外的概念来学习，它们是全局缓存服务和全局