詳情見:https://blog.csdn.net/tianlesoftware/article/details/7777511
一．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 說明
http://blog.csdn.net/tianlesoftware/article/details/6529401
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 層面上進行應用分離，即不同節點處理不同應用，節點之間通過配置，做爲彼此的備用節點，在節點宕機時可以結果相關應用，提供高可用性。
原文鏈接：https://blog.csdn.net/tianlesoftware/article/details/7777511