共享：RAC等待事件:gc buffer busy acquire

ALLSTARS_ORACLE

共享：RAC等待事件: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 (Doc ID 756671.1)

案例分享
---------------------
一个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.

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


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 wait 很高，
segment order by buffer busy部分看到的是索引， 那么是否可以确认是因为insert ,update引起呢。


就是说如果从原理排除了select ,select语句并发引起gc bufer busy 的可能，那么遇到此类等待，就可以将怀疑重点放到insert ,update语句上吧




是有可能的，insert操作需要维护对应的index，index的block就成了热点块了，可以用分区index或者反向index。

winkey

谢谢楼主分享，想问一下在解决索引热块上除了创建反向index（因为很多情况不适合创建反向index）还有别的方式吗？？？

不了峰

winkey 发表于 2014-3-6 00:03
谢谢楼主分享，想问一下在解决索引热块上除了创建反向index（因为很多情况不适合创建反向index）还有别的方 ...

可能可以考虑把单个块索引存储的数据变少一些，比如创建索引时把pctfree加大一些~

winkey

不了峰 发表于 2014-3-6 08:53
可能可以考虑把单个块索引存储的数据变少一些，比如创建索引时把pctfree加大一些~ ...

thanks， 对于比较常用的大index，cache到内存中，对inset，update有影响吗，数据库版本11.2.0.4，
os olinux 5.9

不了峰

winkey 发表于 2014-3-6 10:32
thanks， 对于比较常用的大index，cache到内存中，对inset，update有影响吗，数据库版本11.2.0.4，
os ol ...

理论是上没有影响，应该是更快了才是 如果keep 池足够用的话