gc cr disk read事件
当node 1需要读取的block在node 2的buffer cache里，且block中包含尚未提交的事务，那么node 2的LMS进程需要使用undo record将该block回滚至node 1发起那一时刻的内容后再传给node 1，假如这时undo record所在的undo block不在node 2的buffer cache里，node 1上就会出现gc cr disk read事件，表示node 1正等待node 2的LMS授予其直接从磁盘读取undo block的权限。
gc current block 2-way
node 1、node 2的buffer cache里都没有block A，这时node 1读取了某个block A里的某一行，随后node 2也读取了block A或者对block A里的某一行作了DML操作，这两种情况下node 2上都会出现"gc current block 2-way"等待，current在这里表示node 2读取或修改的block版本是最新的，该block里不存在未提交的事务。值得注意的是在"gc current block 2-way"事件发生之后，GRD里会为该block上KJUSERPR(读操作)或者KJUSEREX锁(写操作)
gc cr block 2-way
细分一下有两种情况
(1)、node 1修改了记录但没有提交：
node 1、node 2的buffer cache里都没有block A，这时node 1修改了block A里的某一行，但没有提交；随后node 2执行了Select block A操作，按照一致性读的定义，node 2此时应该收到block A在select发起那一时刻所对应的快照block A‘，block A‘将由node 1上的LMS进程以应用undo record到block A的方式构造出来后传给node 2，此时在node 2上就发生了一次"gc cr block 2-way"等待事件，node 2接收到的block A‘在buffer cache中标记为cr类型，cr类的block仅满足当次查询的需要，无法被之后的查询所重用，也就是说假如node 2仅接着又发起一次对于block A的select操作，node 1上的LMS进程还是会重新构造出一个block A‘‘后传递给node 2，尽管block A‘‘与block A‘的内容是完全一样的。这一特性决定了cr block在构造及传输的过程中在GRD里不需要任何的锁来保护。
(2)、node 1修改了记录且已经提交：
node 1、node 2的buffer cache里都没有block A，这时node 1修改了block A里的某一行，并且已经提交。因为_fairness_threshold参数的作用，当node 2执行了Select block A操作，仍然有可能触发node 1上的LMS进程构造cr block然后传输给node 2的动作，node 2就会遇到gc cr block 2-way等待。
值得一提的是不管是gc cr block 2-way还是gc current block 2-way，它们的出现并不意味着RAC的性能出现了问题，可以认为这是消息类的等待事件，仅仅表示两节点间存在block的传输，但如果在AWR里发现这两种等待事件平均耗时较长(>10ms)，就可以认为网络上存在瓶颈，需要联系网络管理员介入处理
gc current block busy
node 1正在更新block A的时候node 2也发起了对block A的更新，这时node 2在等待接收node 1上的LMS进程构造出block A在node 2发起更新时刻的block映像，node 2在接收到block A映像之前，就会处于gc current block busy状态
gc cr block busy
当node 1正在更新block A的时候，node 2发起了对block A的查询，这时node 2在等待接收node 1上的LMS进程构造出block A在node 2发起查询时刻的block映像，node 2在接收到block A映像之前，就会处于gc cr block busy状态
gc buffer busy acquire
实例1和实例2的buffer cache都含有某个block，T1时刻实例1修改了这个block，T2时刻实例2上的会话1读取这个block，当这个读取还没有完成，实例2上的会话2也发起了读取相同block的操作，这时会话2就会等在gc buffer busy acquire上。实例2同时发起的读取相同block的会话数越多，我们就越容易观察到gc buffer busy acquire等待。
gc buffer busy release
在session#1尝试请求访问本地实例buffer时，发现之前已经有远程实例的session#2请求访问该buffer，并且没有完成，那么session#1等待gc buffer busy release。
整理自：
那些你眼熟的global cache等待事件是如何被触发的(一)
http://blog.itpub.net/53956/viewspace-2125576/