gc cr multi block request实际就是global cache cr multi block request，10G以后global cache被简称为gc,在RAC应用系统里面，这是一个常见的等待事件。[@more@]
工作原理：
当进程请求数据库块时，首先会在本地的CACHE里面查看是否存在，这种查看是根据DBA (Data Block Address) 转化为cache buffers chains,然后再从hash bucket确认是否存在。
如果在本地没发现有块的CACHE，进程就会请求resource master授予共享访问给数据块，然后再去获取数据块的CACHE。
如果请求的BLOCK CACHE在远程的节点，resource master就会使用内部通讯把远程的CACHE传输到本地。当请求的CACHE BUFFER是共享模式的，远程节点就会克隆一个然后传输到本地。非则，就建立PI映像，然后传输到本地。

数据库现象：
会出现以下类似的等待
SQL> select name from v$event_name where name like 'gc%';
NAME
----------------------------------------------------------------
gc buffer busy
gc current request
gc cr request
gc cr disk request
gc cr multi block request
gc current multi block request
gc block recovery request
这些事件严重影响了数据库的性能，它可能造成查询，修改，建立索引，统计分析异常缓慢。
在V$SESSION里面，可以通过这个等待事件获取到具体的块，如：
SID EVENT P1 P2 P3 MESSAGE
---------- ---------- ---------- ---------- --------- -----------------------------------------------------------
3776 gc current request 542 1871579 33619969 Table Scan: CM_CU_CUSTOMER: 35059 out of 66457 Blocks done
这里的P1,P2,P3分别对应数据文件，块和类别

SQL> select name,PARAMETER1 ,PARAMETER2,PARAMETER3 from v$event_name where name='gc cr multi block request';
NAME PARAMETER1 PARAMETER2 PARAMETER3
------------------------------ ---------- ---------- ----------
gc cr multi block request file# block# class#
如果你“足够”快，可以通过XSBH视图在另一个节点查看到块
SQL> select count(*) from v$bh where FILE#=542 and block#=1871579;
COUNT(*)
----------
0
解决方法：
只要不需要去远程取块的CACHE，那这个等待事件就不会出现。因此，把应用部署在一个节点上，而不是两个节点上。当然，这个应用针对的使大对象，毕竟RAC内部CACHE的传输速度是非常块的都是以CS单位来计算。
如果不可能只在一个节点上部署应用，可以适当调整两节点传输参数和应用来获取平衡。