GC Buffer Busy等待事件

一、原理

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