一．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://www.cndba.cn/Dave/article/939
在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://www.cndba.cn/Dave/article/940
通常，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 說明
javascript:void(0)
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 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
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
global cache prepare failures 8
global cache skip prepare failures 3408
24 rows selected.
注：
該部分内容引自http://book.51cto.com/art/201202/320497.htm
二．gc current/crblock busy等待事件
2.1 gc current block busy 等待事件
When a requestneeds a block in current mode, it sends arequest to the master instance. The requestor evenutally gets the blockvia cache fusion transfer. However sometimes the block transfer isdelayed due to either the block was being used by a session on another instanceor the block transfer was delayed because the holding instance could not writethe corresponding redo records to the online logfile immediately.
--當請求的block是current模式，會發送一個請求到master 執行個體，最終請求者通過cache fusion擷取到這個block。但是有時block在transfer過程中會有延時，比如這個block正在被其他的block使用，或者持有block的執行個體不能及時的将redo records寫入online logfile。
One can use thesession level dynamic performance views v$session and v$session_event to findthe programs or sesions causing the most waits on this events
SQL>selecta.sid , a.time_waited , b.program , b.module from v$session_event a , v$sessionb where a.sid=b.sid and a.event='gc current block busy' order by a.time_waited;
2.2 gc cr block busy 等待事件
When a requestneeds a block in CR mode, it sends arequest to the master instance. The requestor evenutally gets the block viacache fusion transfer. However sometimes the block transfer is delayed due toeither the block was being used by a session on another instance or the blocktransfer was delayed because the holding instance could not write thecorresponding redo records to the online logfile immediately.
One can use thesession level dynamic performance views v$session and v$session_event to find theprograms or sesions causing the most waits on this events
SQL>selecta.sid , a.time_waited , b.program , b.module from v$session_event a ,v$session b where a.sid=b.sid and a.event='gc cr block busy' order bya.time_waited;
2.3 相關說明
gc current blockbusy 等待是RAC中global cache全局緩存目前塊的争用等待事件， 該等待事件時長由三個部分組成：
Time to process current block request inthe cache= (pin time + flush time + send time)
gc current block flush time
The currentblock flush time is part of the service (or processing) time for a currentblock. The pending redo needs to be flushed to the log file by LGWR before LMSsends it. The operation is asynchronous in that LMS queues the request, postsLGWR, and continues processing. The LMS would check its log flush queue forcompletions and then send the block, or go to sleep and be posted by LGWR. Theredo log write time and redo log sync time can influence theoverall service time significantly.
flush time 是Oracle為了保證Instance Recovery執行個體恢複機制，而要求每一個current block在本地節點local instance被修改後(modify/update) 必須要将該current block相關的redo 寫入到logfile 後（要求LGWR必須完成寫入後才能傳回)，才能由LMS程序傳輸給其他節點使用。
而gc buffer busy acquire/release 往往是 gc current block busy的衍生産品， 當同一執行個體内的多個程序并發地通路同一個資料塊時 ，首先發起的程序 将進入 gc current block busy的等待 ，而在 buffer waiter list 上的後續程序 會陷入gc buffer busy acquire/release 等待(A user on the same instance has started a remote operation on thesame resource and the request has not completed yet or the block was requestedby another node and the block has not been released by the local instance whenthe new local access was made)， 這裡存在一個排隊效應， 即 gc current block busy是緩慢的，那麼在 排隊的gc buffer busy acquire/release就會更慢：
Pin time = (timeto read the block into cache) + (time to modify/process the buffer)
Busy time =(average pin time) * (number of interested users waiting ahead of me)
不局限于current block （reference AWR Avg global cache current block flush time(ms)), cr block(Avg global cache cr block flush time (ms)) 也存在flush time。
可以通過設定_cr_server_log_flush to false(LMSare/is waiting for LGWR to flush the pending redo during CR fabrication.Without going too much in to details, you can turn off the behaviourby setting _cr_server_log_flush to false.) 來禁止crserver flush redo log，但是該參數對于current block的flush time無效， 也強烈不推薦使用。
該部分引自ML的論壇：
Oracle gc current block busy 等待事件 說明
http://t.askmaclean.com/viewthread.php?tid=438&highlight=
三．gc cr multi blockrequest等待事件
gc cr multiblock request實際就是globalcache cr multi block request，10G以後global cache被簡稱為gc,在RAC應用系統裡面，這是一個常見的等待事件。
multi block一般情況下都是全表掃描或全索引掃描導緻， gc cr multiblock request 會造成CPU 對記憶體的排程和管理，會消耗CPU 時間。
gc cr multiblock request 問題應在rac 層面上進行應用分離，即不同節點處理不同應用，節點之間通過配置，做為彼此的備用節點，在節點當機時可以結果相關應用，提供高可用性。