常見的global cache等待事件

gc cr disk read事件

當node 1需要讀取的block在node 2的buffer cache里，且block中包含尚未提交的事務，那么node 2的LMS進程需要使用undo record將該block回滾至node 1發起那一時刻的內容后再傳給node 1，假如這時undo record所在的undo block不在node 2的buffer cache里，node 1上就會出現gc cr disk read事件，表示node 1正等待node 2的LMS授予其直接從磁盤讀取undo block的權限。

gc current block 2-way

node 1、node 2的buffer cache里都沒有block A，這時node 1讀取了某個block A里的某一行，隨后node 2也讀取了block A或者對block A里的某一行作了DML操作，這兩種情況下node 2上都會出現"gc current block 2-way"等待，current在這里表示node 2讀取或修改的block版本是最新的，該block里不存在未提交的事務。值得注意的是在"gc current block 2-way"事件發生之后，GRD里會為該block上KJUSERPR(讀操作)或者KJUSEREX鎖(寫操作)

gc cr block 2-way

細分一下有兩種情況

(1)、node 1修改了記錄但沒有提交：

node 1、node 2的buffer cache里都沒有block A，這時node 1修改了block A里的某一行，但沒有提交；隨后node 2執行了Select block A操作，按照一致性讀的定義，node 2此時應該收到block A在select發起那一時刻所對應的快照block A'，block A'將由node 1上的LMS進程以應用undo record到block A的方式構造出來后傳給node 2，此時在node 2上就發生了一次"gc cr block 2-way"等待事件，node 2接收到的block A'在buffer cache中標記為cr類型，cr類的block僅滿足當次查詢的需要，無法被之后的查詢所重用，也就是說假如node 2僅接著又發起一次對于block A的select操作，node 1上的LMS進程還是會重新構造出一個block A''后傳遞給node 2，盡管block A''與block A'的內容是完全一樣的。這一特性決定了cr block在構造及傳輸的過程中在GRD里不需要任何的鎖來保護。

(2)、node 1修改了記錄且已經提交：

node 1、node 2的buffer cache里都沒有block A，這時node 1修改了block A里的某一行，并且已經提交。因為_fairness_threshold參數的作用，當node 2執行了Select block A操作，仍然有可能觸發node 1上的LMS進程構造cr block然后傳輸給node 2的動作，node 2就會遇到gc cr block 2-way等待。

值得一提的是不管是gc cr block 2-way還是gc current block 2-way，它們的出現并不意味著RAC的性能出現了問題，可以認為這是消息類的等待事件，僅僅表示兩節點間存在block的傳輸，但如果在AWR里發現這兩種等待事件平均耗時較長(>10ms)，就可以認為網絡上存在瓶頸，需要聯系網絡管理員介入處理

gc current block busy

node 1正在更新block A的時候node 2也發起了對block A的更新，這時node 2在等待接收node 1上的LMS進程構造出block A在node 2發起更新時刻的block映像，node 2在接收到block A映像之前，就會處于gc current block busy狀態

gc cr block busy

當node 1正在更新block A的時候，node 2發起了對block A的查詢，這時node 2在等待接收node 1上的LMS進程構造出block A在node 2發起查詢時刻的block映像，node 2在接收到block A映像之前，就會處于gc cr block busy狀態

gc buffer busy acquire

實例1和實例2的buffer cache都含有某個block，T1時刻實例1修改了這個block，T2時刻實例2上的會話1讀取這個block，當這個讀取還沒有完成，實例2上的會話2也發起了讀取相同block的操作，這時會話2就會等在gc buffer busy acquire上。實例2同時發起的讀取相同block的會話數越多，我們就越容易觀察到gc buffer busy acquire等待。

gc buffer busy release

在session#1嘗試請求訪問本地實例buffer時，發現之前已經有遠程實例的session#2請求訪問該buffer，并且沒有完成，那么session#1等待gc buffer busy release。

整理自：

那些你眼熟的global cache等待事件是如何被觸發的(一) 

http://blog.itpub.net/53956/viewspace-2125576/