oracle rac 热块处理(ITL waits)

看了老白的RAC日记，总结一下。

分析AWR信息 Top Events

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Event                             Waits            time(s)   %Total Ela Time

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

enqueue                           1,872.325        85.528    39.87

buffer busy global cache          218,188          34.053    15.88

db file sequential read           1,366.797        20.368    9.50

log file sync                     499.127          20.099    9.37

buffer busy waits                 216.884          9.241     8.97

从Top 5 Events上来看，Enqueue等待占了近40%,buffer busy global cache 等待占15.88%，这是典型的全局热块冲突现象。看样子解决热块冲突是最终解决问题的关键。下面是热块冲突相关的等待情况：

Class                            Waits          Total  Wait Time(s)     Avg Time(ms)

data block                     108,5360         10200                      9

1st level bmb                  7930             10                         1

undo header                    2820             0                          0

2nd level bmb                  560              0                          0

segment header                 520              0                          0

undo block                     3                0                          0

 

数据块等待居多

 

从锁等待的情况来看，主要的等待还是TX锁，从这里也可以为我刚才的热块冲突导致问题提供一个旁证。锁等待过高的原因不是因为oracle内部锁，而是因为TX事务锁导致。

主要等待是TX,buffer busy global cr 和buffer busy wait

查看V$LOCK

select * from v$lock
where type = 'TX

主要都是TX锁,LMODE=4是共享模式，LMODE=6是排他模式。如果存在大量的LMODE=4的锁请求，那说明可能ITL存在等待现象，因为LMODE为4一般来说可能是ITL等待或者等待索引页节点分裂，接下来查看ITL等待情况

select t.OWNER,t.OBJECT_NAME,t.OBJECT_TYPE,t.STATISTIC_NAME,t.VALUE value
from v$segment_statistics t
where t.STATISTIC_NAME = 'ITL waits'
and t.VALUE > 0 order by value

这个查询排在前几位的对象都是我们需要关注的。从查询的结果来看，排在前面的10几张表和索引都有大量的ITL等待。查看这几张表，发现这些表的存储参数中initrans都是2,pctfree都是缺省的10。initrans是导致问题的元凶，建议把这些表和索引的inittans加大为10，并且最好把相关的表和索引都重建一下。

重建索引时，如果断开，可能会报错ora-08104,这时需要DBMS_REPAIR.ONLINE_INDEX_CLEAN 清理掉，再重建就好了