一、原理
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無效， 也強烈不推薦使用。
二、案例1
1.RAC負載均衡下併發insert很容易造成gc buffer busy acquire。
2.本實例第一個申請該current block時進入gc current request，本實例後續其他進程若又發起對該current block的申請則均進入’gc buffer busy acquire’等待。
3.11g後gc buffer busy分成 ’gc buffer busy acquire’ 和 ’gc buffer busy release。
三、案例2
1.從上面例子可以看出Redo flush慢造成的gc buffer busy release/acquire
2.flush time 是Oracle爲了保證Instance Recovery實例恢復機制，而要求每一個current block在本地節點local instance被修改後(modify/update) 必須要將該current block相關的redo 寫入到logfile 後（要求LGWR必須完成寫入後才能返回)，才能由LMS進程傳輸給其他節點使用。
1.一般Flushes要小於5ms。
1.busy指標都比較高
本文出自 “無雙城” 博客，請務必保留此出處http://929044991.blog.51cto.com/1758347/1264077