OracleRAC学习之--OPS中的RACPing和RACCacheFusion一、OPS中的RACPing二、RAC中的CacheFusion什么是CacheFusion?&n..
oracle rac学习之--ops中的rac ping和rac cache fusion
一、OPS中的RAC Ping
二、RAC中的Cache Fusion
什么是Cache Fusion?
Cache Fusion就是通过互联网络在集群内各节点的SGA之间进行块传递，以避免首先将块推送到磁盘，然后再重新读入其他实例的缓存中这样一种低效的实现方式(OPS的实现)。当一个块被读入RAC环境中某个实例的缓存时，该块会被赋予一个锁资源（与行级锁不同），以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过互联网络直接被传递到另一个实例的SGA。如果内存中的块已经被改变，但改变尚未提交，，那么将会传递一个CR副本。这就意味着只要可能，数据块无需写回磁盘即可在各实例的缓存之间移动，从而避免了同步多实例的缓存所花费的额外I/O。很明显，不同的实例缓存的数据可以是不同的，也就是在一个实例要访问特定块之前，而它又从未访问过这个块，那么它要么从其他实例cache fusion过来，或者从磁盘中读入。
这里还是有一些问题需要思考的：
1、在所有实例都未读取该块，而第一个实例读取时，是怎么加的锁，加的什么锁？如果此时有另一个实例也要读这个块，几乎是同时的，那么Oracle如何来仲裁，如何让其中一个读取，而另一个再从前者的缓存中通过cache来得到？
2、如果一个块已经被其他实例读入，那么本实例如何判断它的存在？
3、如果某个实例改变了这个数据块，是否会将改变传递到其他实例，或者说其他实例是否会知道并重新更新状态？
4、如果一个实例要swap out 某个块，而同时其他实例也有这个块的缓存，修改过的和未修改过的，本实例修改的和其他实例修改的，如何操作? truncate一张表，drop一张表... 和单实例有何不同？
5、应该如何设计应用，以使RAC真正发挥作用，而不是引入竞争，导致系统被削弱？
6、RAC下锁的实现。锁是在各实例的SGA中保留的资源，通常被用于控制对数据库块的访问。每个实例通常会保留或控制一定数量与块范围相关的锁。当一个实例请求一个块时，该块必须获得一个锁，并且锁必须来自当前控制这些锁的实例。也就是锁被分布在不同的实例上。而要获得特定的锁要从不同的实例上去获得。但是从这个过程来看这些锁不是固定在某个实例上的，而是根据锁的请求频率会被调整到使用最频繁的实例上，从而提高效率。
对于前面的一些问题，可以结合另外的概念来学习，它们是全局缓存服务和全局队列服务。
全局缓存服务(GCS):
全局缓存要涉及到数据块。全局缓存服务负责维护该全局缓冲存储区内的缓存一致性，确保一个实例在任何时刻想修改一个数据块时，都可获得一个全局锁资源，从而避免另一个实例同时修改该块的可能性。进行修改的实例将拥有块的当前版本（包括已提交的和未提交的事物）以及块的前象(post image)。如果另一个实例也请求该块，那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本是什么，以及块处于何种模式。LMS进程是全局缓存服务的关键组成部分。
全局队列服务(GES)：
Global Enqueue Service (GES) tracks the status of all Oracle enqueuing mechanism.主要负责维护字典缓存和库缓存内的一致性。字典缓存是实例的SGA内所存储的对数据字典信息的缓存，用于高速访问。由于该字典信息存储在内存中，因而在某个节点上对字典进行的修改（如DDL)必须立即被传播至所有节点上的字典缓存。GES负责处理上述情况，并消除实例间出现的差异。处于同样的原因，为了分析影响这些对象的SQL语句，数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进行维护，而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。LMON、LCK和LMD进程联合工作来实现全局队列服务的功能。GES是除了数据块本身的维护和管理（由GCS完成）之外，在RAC环境中调节节点间其他资源的重要服务。
查看GCS和GES:
SQL> set linesize 1000
SQL> select * from gv$sysstat where name like 'gcs %'
SQL> select * from gv$sysstat where name like 'ges %';
Write/Write Cache Fusion – GCS Processing
Blocks to Disk – GCS Processing
