er
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》
|