在RAC环境中，和全局调整缓存相关的最常见的等待事件无非就是：global cache cr request，global cache busy和equeue
在XX电信做了一次数据库巡检中发现，spreport中的top 5 wait events中出现了global cache cr request等待事件，
那么这个等待事件是什么原因引起的呢？
首先，我们来看看这个等待事件是如何产生的，当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。假如，通过global cache 发现这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHE FUSION,在节点之间直接传递，
同时出现global cache cr request等待事件
注意：在10G中，global cache cr request 已经简称为 gc cr request
从remote cache运输块到本地cache花费的时间还得看这些块是共享还是独占模式，如果块是共享(scur)的，REMOTE CACHE就克隆信息传送过来，否则就要产生一个PI，然后再传送过去。显然，global cache cr request等待事件和db file sequential/scattered read 等待事件有着直接的关系。
通常，RAC中的进程会等待1S去尝试从本地或者远程CACHE读取数据块信息，当然，这还得依靠块处于什么样的模式。如果超过了1S，那就表明节点之间连接慢，这个时候节点之间就使用private连接，而 客户端的连接使用public，有时候，节点之间的连接， Cache Fusion就不会通过公共网络，在这种情况下，就会有大量的global cache cr request等待事件出现，你可以使用oradebug ipc命令去验证下节点之间的连接是否使用了private network。
例如：
SQL> oradebug setmypid
Statement processed.
SQL> oradebug ipc
Information written to trace file.
SQL> oradebug tracefile_name
/home/oracle/admin/rac/udump/rac1_ora_3194.trc
SKGXPCTX: 0xb3ca990 ctx
admono 0x1e00b916 admport:
SSKGXPT 0xb3caa78 flags info for network 0
socket no 8 IP 192.168.1.1 UDP 53064
sflags SSKGXPT_UP
info for network 1
socket no 0 IP 0.0.0.0 UDP 0
sflags SSKGXPT_DOWN
active 0 actcnt 1
context timestamp 0
从上面你可以看到IP 92.168.1.1在Cache Fusion使用，而且协议是UDP默认情况下，节点之间的连接是采取TCP协议的，为了更改这个而使用告诉内部连接，你需要进行以下操作。例如，默认情况下，在LINUX操作系统上，节点之间的连接使用UDP，这个信息你可以从后台日志中看到：
cluster interconnect IPC version:Oracle UDP/IP
IPC Vendor 1 proto 2 Version 1.0
为了使用高速连接，关闭ORACLE所有服务，重新连接如下：
$ make -f ins_rdbms.mk rac_on ipc_hms ioracle
如果你想重新使用UDP，则
$ make -f ins_rdbms.mk rac_on ipc_udp ioracle
当会话从开始提交一致读的请求，到它获取请求信息，这个过程它是SLEEP状态的，对我们而言吹降木褪?/span>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 v$sysstat where name like '%global cache%';
NAME VALUE
---------------------------------------------------------------- ----------
global cache gets 1791587
global cache get time 85911
global cache converts 179612
global cache convert time 1262
global cache cr blocks received 17189
global cache cr block receive time 31547
global cache current blocks received 4627
global cache current block receive time 763
global cache cr blocks served 16805
global cache cr block build time 72
global cache cr block flush time 25043
NAME VALUE
---------------------------------------------------------------- ----------
global cache cr block send time 54
global cache current blocks served 3529
global cache current block pin time 21
global cache current block flush time 0
global cache current block send time 15
global cache freelist waits 285
global cache defers 2
global cache convert timeouts 0
global cache blocks lost 0
global cache claim blocks lost 0
global cache blocks corrupt 0
NAME VALUE
---------------------------------------------------------------- ----------
global cache prepare failures 8
global cache skip prepare failures 3408
24 rows selected.
通过查询V$BH视图，获取当前缓冲区的信息：
SQL> select status,count(*)from v$bh group by status;
STATU COUNT(*)
----- ----------
cr 67
free 8571
scur 10636
xcur 43094
上面的2，4可通过减少PI和缓冲区的CR拷贝缓解global cache cr request等待事件，
实际上2的处理方法和处理db file sequential/scattered read 等待事件是一样的，这里不在叙述。
在RAC环境中，和全局调整缓存相关的最常见的等待事件无非就是：global cache cr request，global cache busy和equeue
在XX电信做了一次数据库巡检中发现，spreport中的top 5 wait events中出现了global cache cr request等待事件，
那么这个等待事件是什么原因引起的呢？
首先，我们来看看这个等待事件是如何产生的，当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。假如，通过global cache 发现这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHE FUSION,在节点之间直接传递，
同时出现global cache cr request等待事件
注意：在10G中，global cache cr request 已经简称为 gc cr request
从remote cache运输块到本地cache花费的时间还得看这些块是共享还是独占模式，如果块是共享(scur)的，REMOTE CACHE就克隆信息传送过来，否则就要产生一个PI，然后再传送过去。显然，global cache cr request等待事件和db file sequential/scattered read 等待事件有着直接的关系。
通常，RAC中的进程会等待1S去尝试从本地或者远程CACHE读取数据块信息，当然，这还得依靠块处于什么样的模式。如果超过了1S，那就表明节点之间连接慢，这个时候节点之间就使用private连接，而 客户端的连接使用public，有时候，节点之间的连接， Cache Fusion就不会通过公共网络，在这种情况下，就会有大量的global cache cr request等待事件出现，你可以使用oradebug ipc命令去验证下节点之间的连接是否使用了private network。
例如：
SQL> oradebug setmypid
Statement processed.
SQL> oradebug ipc
Information written to trace file.
SQL> oradebug tracefile_name
/home/oracle/admin/rac/udump/rac1_ora_3194.trc
SKGXPCTX: 0xb3ca990 ctx
admono 0x1e00b916 admport:
SSKGXPT 0xb3caa78 flags info for network 0
socket no 8 IP 192.168.1.1 UDP 53064
sflags SSKGXPT_UP
info for network 1
socket no 0 IP 0.0.0.0 UDP 0
sflags SSKGXPT_DOWN
active 0 actcnt 1
context timestamp 0
从上面你可以看到IP 92.168.1.1在Cache Fusion使用，而且协议是UDP默认情况下，节点之间的连接是采取TCP协议的，为了更改这个而使用告诉内部连接，你需要进行以下操作。例如，默认情况下，在LINUX操作系统上，节点之间的连接使用UDP，这个信息你可以从后台日志中看到：
cluster interconnect IPC version:Oracle UDP/IP
IPC Vendor 1 proto 2 Version 1.0
为了使用高速连接，关闭ORACLE所有服务，重新连接如下：
$ make -f ins_rdbms.mk rac_on ipc_hms ioracle
如果你想重新使用UDP，则
$ make -f ins_rdbms.mk rac_on ipc_udp ioracle
当会话从开始提交一致读的请求，到它获取请求信息，这个过程它是SLEEP状态的，对我们而言吹降木褪?/span>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 v$sysstat where name like '%global cache%';
NAME VALUE
---------------------------------------------------------------- ----------
global cache gets 1791587
global cache get time 85911
global cache converts 179612
global cache convert time 1262
global cache cr blocks received 17189
global cache cr block receive time 31547
global cache current blocks received 4627
global cache current block receive time 763
global cache cr blocks served 16805
global cache cr block build time 72
global cache cr block flush time 25043
NAME VALUE
---------------------------------------------------------------- ----------
global cache cr block send time 54
global cache current blocks served 3529
global cache current block pin time 21
global cache current block flush time 0
global cache current block send time 15
global cache freelist waits 285
global cache defers 2
global cache convert timeouts 0
global cache blocks lost 0
global cache claim blocks lost 0
global cache blocks corrupt 0
NAME VALUE
---------------------------------------------------------------- ----------
global cache prepare failures 8
global cache skip prepare failures 3408
24 rows selected.
通过查询V$BH视图，获取当前缓冲区的信息：
SQL> select status,count(*)from v$bh group by status;
STATU COUNT(*)
----- ----------
cr 67
free 8571
scur 10636
xcur 43094
上面的2，4可通过减少PI和缓冲区的CR拷贝缓解global cache cr request等待事件，
实际上2的处理方法和处理db file sequential/scattered read 等待事件是一样的，这里不在叙述。