常見的global cache等待事件

gc cr disk read事件

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

gc current block 2-way

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

gc cr block 2-way

細(xì)分一下有兩種情況

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

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

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

node 1、node 2的buffer cache里都沒有block A，這時(shí)node 1修改了block A里的某一行，并且已經(jīng)提交。因?yàn)開fairness_threshold參數(shù)的作用，當(dāng)node 2執(zhí)行了Select block A操作，仍然有可能觸發(fā)node 1上的LMS進(jìn)程構(gòu)造cr block然后傳輸給node 2的動(dòng)作，node 2就會(huì)遇到gc cr block 2-way等待。

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

gc current block busy

node 1正在更新block A的時(shí)候node 2也發(fā)起了對(duì)block A的更新，這時(shí)node 2在等待接收node 1上的LMS進(jìn)程構(gòu)造出block A在node 2發(fā)起更新時(shí)刻的block映像，node 2在接收到block A映像之前，就會(huì)處于gc current block busy狀態(tài)

gc cr block busy

當(dāng)node 1正在更新block A的時(shí)候，node 2發(fā)起了對(duì)block A的查詢，這時(shí)node 2在等待接收node 1上的LMS進(jìn)程構(gòu)造出block A在node 2發(fā)起查詢時(shí)刻的block映像，node 2在接收到block A映像之前，就會(huì)處于gc cr block busy狀態(tài)

gc buffer busy acquire

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

gc buffer busy release

在session#1嘗試請(qǐng)求訪問本地實(shí)例buffer時(shí)，發(fā)現(xiàn)之前已經(jīng)有遠(yuǎn)程實(shí)例的session#2請(qǐng)求訪問該buffer，并且沒有完成，那么session#1等待gc buffer busy release。

整理自：

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

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