gc buffer busy的优化

12-SEP-07 09.00.17.451 AM      12-SEP-07 05.00.03.683

查看过去一段时间的等待事件类型汇总

select wait_class_id, wait_class, count(*) cnt

from dba_hist_active_sess_history

where snap_id between 12831 and 12838

group by wait_class_id, wait_class

order by 3;

   1740759767 User I/O                           121999

可以更细化为具体的等待事件

1478861578 gc buffer busy                                67275

--在这段时间内累计有67275个session等待gc buffer busy,然后查看出是哪些sql引起的

8v3b2m405atgy      42292

运行次数最多的sql达到4万多次，通过dba_hist_sqltext查看出对应的sql

insert into bigtable(id, version, client, cl_business_id, cl_order_id, desc。。。。。

该表是个分区表，且其上有很多trigger和大量的索引，需要明确该sql等待的对象

后三个是次数比较多的

   3208620 JSCHDER    BIGTABL_LG_X_CHANGE_DATE       P_2007_09                      INDEX PARTITION

等待次数最多的却是bigtable_log，这是因为表上有一个trigger,每对bigtable更新一次，就要往该表insert7次；

我们可以进一步确认那些块竞争最激烈

         1487         233206        120

似乎并没有过热的块，因为有超过4万个session访问这些object，但等待次数最多的块只有120次；

检查一下这些块是否为段头块，

BIGTABLE_LOG                          1209        16393

可惜这些只是普通的数据块。

任何时候，只要表数据块在insert时候有严重的并发问题，首先要想到的就是space management;

检查该表所属表空间的管理方式

 

1                        1

其表空间使用手工段管理且只有一个freelist;

小结：这是一个6节点RAC，最忙的表却只有一个freelist，难怪会引起严重的gc buffer busy；

但是因为每个块都很快的被填满，所以没有等待次数过多的块；

不需要考虑ITL的问题，因为插入的都是空块，ITL如果不够会自动分配直到块满为止；

该系统是从non-rac升级到RAC的，因此所有的object都是MSSM，解决完这个object其他object的问题则会后续显现；

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15480802/viewspace-712622/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15480802/viewspace-712622/