RAC中一次混乱的性能诊断过程

   众所周知在RAC中，问题很可能来自于CACHE FUSION（内存融合）的机制，简单的说就是CACHE BUFFER中的块在内存融合的机制下通过LMD进程进行传递，比如我节点1需要访问数据块A，通过SEND MESSAGE到MASTER节点询问块A所在的节点，MASTER告诉节点1 A块在节点2的BUFFER CACHE中，这个时候又可能是当前读和一致性读，如果块正在被修改就会构架PI来进行一致性读，传递块给节点1，这个时候PCM锁是X模式，如果当前块A没有被修改，只是被节点2SELECT，这个时候就是当前读，传递当前块给节点1，这个时候PCM锁是S模式，这个大概就是内存融合的机制。

  最近遇到一个问题我们数据库服务器在高负载的情况下，CPU降低到40%左右，我试图找到问题，因为数据库服务器是RAC，并且AWRRPT的TOP5 EVENT如下：

Top 5 Timed Events

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
CPU time		4,677		79.7
gc cr multi block request	6,108,620	793	0	13.5	Cluster
gc buffer busy	117,685	138	1	2.3	Cluster
db file sequential read	65,355	105	2	1.8	User I/O
gc current block 2-way	205,250	79	0	1.3	Cluster

 

首先可以肯定的是这个问题绝对是处在块传递上，解决这样的问题有2个方法

1、  用SERVICE 来分离业务，通过分离业务让特定的数据块只在指定的节点里进行访问，避免传递。

2、  尽可能的减少逻辑读，逻辑读少了自然传递的可能性就小了，也就是这一点让我前期的诊断陷入了错误的方向。

分离业务是不能的，因为牵涉太大，所以我自然而然的想到了减少逻辑读，带着这个理念我进入了查看SQL的阶段，首先当然是查看最耗时的SQL