RAC遇到GC Buffer Busy的解决方法
2010年07月06日 作者： 大头刚
一朋友求助说他的ORACLE RAC服务器负载不是很稳定，时高时低，且没有任何规律。摘取负载高峰时间的一段日志来分析，最大的等待如下：
^LTop SQL Statements DB/Inst: BOSSCENT/bosscent1 (May 19 13:17 to 13:32) SQL ID Planhash % Activity Event % Event ------------- ----------- ---------- ------------------------------ ---------- f9rf7a8cg40nt N/A 9.14 gc buffer busy 2.53 insert into test(id,user_id,point_num,time,point_gettype,sex) values( :1,:2,:3,sysdate,:4,:5) N/A 9.14 gc current block busy 2.22 insert into test(id,user_id,point_num,time,point_gettype,sex) values( :1,:2,:3,sysdate,:4,:5) N/A 9.14 gc current block 2-way 1.42 insert into test(id,user_id,point_num,time,point_gettype,sex) values( :1,:2,:3,sysdate,:4,:5) bs6z6hs8sum53 1007834728 8.09 gc buffer busy 2.16 update test set id=:1 where id=:2
明显看到出现大量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，也就是实例编号，这个字段作为主分区字段，按照这个分区做范围分区。并且每次插入的时候给这个字段赋一个常量，也就是实例编号。
这样的缺点是，需要修改表结构，风险很大，而且如果以后扩展节点的话，还需要重新改表结构。
两种方法各有长短，需要根据实际情况选择，不过我个人还是倾向于第一种方法。
- Comments (0)
- Trackbacks (0)
Leave a comment TrackbackNo comments yet.
No trackback yet.