一．RAC 全局等待事件说明

在RAC环境中，和全局调整缓存相关的最常见的等待事件是global cache cr request，global cache busy和equeue。

当一个进程访问需要一个或者多个块时，Oracle会首先检查自己的Cache是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。假如，通过global cache发现这些块已经在另一个实例的Cache里面，那么这些块就会通过Cache Fusion，在节点之间直接传递，同时出现global cache crrequest等待事件。

关于Cache Fusion的更多内容参考：

Oracle RACCache Fusion 机制 详解

http://blog.csdn.net/tianlesoftware/article/details/6534239

在10GB中，global cachecr request已经简称为gc crrequest。

从remote cache运输块到本地cache花费的时间还得看这些块是共享还是独占模式，如果块是共享(scur)的，Remote Cache就克隆信息传送过来，否则就要产生一个PI，然后再传送过去。显然，global cache cr request等待事件和db file sequential/scatteredread 等待事件有着直接的关系。

Oracle RACPast Image(PI) 说明

http://blog.csdn.net/tianlesoftware/article/details/6529870

通常，RAC中的进程会等待1s去尝试从本地或者远程Cache读取数据块信息，当然，这还得依靠块处于什么样的模式。如果超过了1s，那就表明节点之间连接慢，这个时候节点之间就使用private连接，而客户端的连接使用public，有时候，节点之间的连接， Cache Fusion就不会通过公共网络，在这种情况下，就会有大量的global cachecr request等待事件出现，可以使用oradebugipc命令去验证下节点之间的连接是否使用了private network。

在下图中，上面的gc [current/cr] [multiblock] request实际上就是placeholder的event，图的左上角也做了说明。

gc [current/cr][multiblock] request实际上是表示了4个事件中的一个（gccurrent request、gc cr request、gc current multiblock request、gc cr multiblock request）。

这里CR和current 是不同的概念，如果是读的话，那就是cr request，如果是更改的话，那就是current request。

CR (consistent read) blocks create 说明

http://blog.csdn.net/tianlesoftware/article/details/6529401

Oracle 10g在很多地方区分了multi block request还是single block request，这样容易分析业务的数据特点。当在RAC环境下，一个session请求一个block的时候，就会触发这个事件。

当请求一个block时，如果经过两个或者3个network hop就获得了该块的话，那就会产生gc [current/cr][2/3]-way。如果是3-way，那应该master和holder不是同一个instance，如果是2-way，那就应该master和holder是同一个instance。这应该是最好的情况，请求后，就获得了请求的block即没有busy，也没有说在请求的过程中等待。该类事件应该暗示是进行了block的网络传递，会产生流量，而grant 2-way的网络流量应该相对小。

gc [current/cr]block busy是说虽然也返回了，但是没有immediatesend，也就是控制流程返回了，但是实际的block并没有马上传递到requesterinstance，gc[current/cr] block busy是和gc [current/cr] [2/3]-way对应的。

gc [current/cr]grant 2-way当请求一个block时，接收了一个message，该message应该是赋予了requester instance可以访问这个block。如果这个block没有在local cache中，则随后的动作就是去磁盘上读该block。（插一点别的，Oracle的对数据的访问的控制，是在row级别和object级别，但是实际操作的对象却是block，传递的对象也是block，对于一个block来说，会有一个master instance，也就是这个block的管理者，然后还有零到多个参与者，比如有的instance为了读一致性，可能会在自己的local cache中存着该block的过去某个时间的image，有的instace为了修改该block，可能会在自己的local cache中存着该block的past image）。

gc current grantbusy当一个instance请求一个block时，被告诉是busy的。不明白在什么情况下会产生grant busy的事件。

gc [current/cr][block/grant] congested对这几个事件的理解是无论对于current还是cr类型的block或者grant，都获得了事件，但是在过程中有拥堵。也就是在内部的队列中等待超过1 ns（纳秒）。

gc [current/cr][failure/retry]这就是发生错误了，没有请求到block.

gc buffer busy是多个进程在同时访问一个block，造成锁竞争了。用RAC就一定要将各个节点隔离化，不管是通过业务隔离，区域隔离还是什么其他隔离手段，最终的目的，就是要各个节点所承担的业务，访问不同的数据对象，最大可能地减少节点间的资源争用，才能发挥RAC集群系统的最大性能。

当会话从开始提交一致读的请求，到它获取请求信息，这个过程它是SLEEP状态的，对用户而言，看到的就是global cache cr request等待事件，而wait time就是记录这个过程的时间。

通常，大量的global cache cr request主要有以下几个原因。

（1）节点之间内部连接慢或者节点之间传输带宽窄。这个可以通过重新连接获取高速连接。

（2）存在热点数据块的竞争。

（3）CPU负载过高或者LMS后台进程不够。正常情况下，只有两个LMS后台进程从CPU那里获取资源，增加LMS进程的数量或者提高它的优先权能够帮助从CPU那里获取更多的资源。隐藏参数_lm_lms是设置LMS进程数量的。

（4）大量未提交的事务或者系统磁盘设备传输慢。

有关global cache的信息：

SQL> select name,value from&n