gc buffer busy acquire

gc buffer busy是RAC数据库中常见的等待事件，11g开始gc buffer  busy分为gc buffer busy acquire和gc buffer  busy release。

gc buffer busy acquire是当session#1尝试请求访问远程实例(remote  instance) buffer，但是在session#1之前已经有相同实例上另外一个session#2请求访问了相同的buffer，并且没有完成，那么session#1等待gc buffer busy acquire。

gc buffer busy release是在session#1之前已经有远程实例的session#2请求访问了相同的buffer，并且没有完成，那么session#1等待gc buffer busy release。

原因/解决方法
---------------------
- 热点块(hot block)
在AWR中Segments by Global Cache Buffer Busy 记录了访问频繁的gc buffer.
解决方法可以根据热点块的类型采取不同的解决方法，比如采取分区表，分区索引，反向index等等。这点与单机数据库中的buffer busy waits类似。

- 低效SQL语句
低效SQL语句会导致不必要的buffer被请求访问，增加了buffer busy的机会。在AWR中可以找到TOP SQL。解决方法可以优化SQL语句减少buffer访问。这点与单机数据库中的buffer busy waits类似。

- 数据交叉访问。
RAC数据库，同一数据在不同数据库实例上被请求访问。
如果应用程序可以实现，那么我们建议不同的应用功能/模块数据分布在不同的数据库实例上被访问，避免同一数据被多个实例交叉访问，可以减少buffer的争用，避免gc等待。

- Oracle bug
建议安装Oracle推荐的最新Patch Set和PSU。
Patch set和PSU信息请参考：Oracle Recommended Patches -- Oracle Database ()
案例分享
---------------------
一个gc buffer busy acquire的案例，和大家分享一下。

- 应用端反映业务处理异常，数据库hang，在第一时间现场DBA收集了hanganalyze (hanganalyze对于分析数据库hang非常重要)

RAC数据库收集hanganalyze的命令：
SQL> conn / as sysdba
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug -g all hanganalyze 3

通过hanganalyze我们可以比较容易看到有1000个以上的Chain都有类似的等待关系，比如：

Chain 1 Signature: 'gc current request'<='gc buffer busy acquire'<='enq: TX -  contention'
Chain 2 Signature: 'gc current request'<='gc buffer busy  acquire'<='buffer busy waits'
…

Chain 1243 Signature: 'gc current request'<='gc buffer busy  acquire'<='enq: TA - contention'
Chain 1244 Signature: 'gc current request'<='gc buffer busy  acquire'<='enq: TA - contention'

Hanganalyze说明数据库中大部分session直接或者间接等待'gc  current request'<='gc buffer busy acquire'。

- 有些情况下dia0 trace文件也会记录hang信息

  inst# SessId  Ser#     OSPID PrcNm Event

  ----- ------ ----- --------- ----- -----

      1   1152     3  21364904    FG gc buffer busy acquire

      1   2481     3  26607642    FG gc current request

Chain 1 Signature: 'gc current request'<='gc buffer busy acquire'

Chain 1 Signature Hash: 0x8823aa2a 

- 有些情况下dba_hist_active_sess_history也会记录hang信息。

详细信息参见blog：RAC等待事件:gc buffer busy acquire

通过分析dba_hist_active_sess_history，也可以得到session等待关系:

'gc current request'<='gc buffer busy  acquire'<='enq: TA - contention'
这个等待关系与hanganalyze是一致的。

- 根据以上分析得到session等待关系，可以确定数据库hang的原因是oracle已知问题Bug

13787307 - Hang in RAC with 'gc current request'<='gc buffer busy acquire'  signature.

- 解决方法：
安装 或者 设置_gc_bypass_readers=false临时规避这个问题。
另外，在11.2低版本中也有些类似的已知问题，建议安装最新patch set (11.2.0.3/4) + 最新PSU 。
Patch set和PSU信息请参考：Oracle Recommended Patches -- Oracle Database ()

1. 查询一般以shared模式请求buffer，但是如果buffer不在buffer cache中，那么需要IO将buffer 读到内存中，这个过程需要

以eXclusive模式，如果同时有大量其他的session也请求查询该buffer（以shared 模式请求），那么就会有buffer等待了。

2. 如果查询请求的block已经被修改了，查询需要访问CR块，为了重构CR块，需要读取对应的undo block，如果undo block不在buffer中，

需要IO把undo block读到内存，如果有大量查询访问这个CR块，那么都会有buffer busy等待了。

处理方案:

看到出现大量gc buffer busy等待，与单实例不同，在RAC环境中，由于多节点的原因，会因为节点间的资源争用产生GC类的等待，而这其中，GC Buffer Busy Waits又是最为常见的，我们看下ORACLE官方对这个等待事件的解释：

gc buffer busy:
This wait event,also known as global cache buffer busy prior to Oracle 10g,specifies the time the remote instance locally spends accessing the requested data block. This wait event is very similar to the buffer busy waits wait event in a single-instance database 。

那么如何解决gc buffer busy带来的性能问题？一般有两种方法：


一、分割应用
就是指把出现gc buffer busy等待的SQL，单独配置一个数据源，在执行的时候指定到集群中的某一个实例。在执行产生gc buffer busy的SQL的时候，使用这个数据源。

这样的缺点是，如果指向一个单实例，这些操作负载太高的话，一个实例可能会抗不住。

二、修改表底层结构

在问题表上加入一个字段inst_id，也就是实例编号，这个字段作为主分区字段，按照这个分区做范围分区。并且每次插入的时候给这个字段赋一个常量，也就是实例编号。

这样的缺点是，需要修改表结构，风险很大，而且如果以后扩展节点的话，还需要重新改表结构。

两种方法各有长短，需要根据实际情况选择，不过我个人还是倾向于第一种方法。