1、背景描述：

某客户反馈在 18 点 30 分左右出现性能问题，活动会话飙升，业务卡顿。

2、问题分析

通过awr 可以看到大量的索引分裂等待，和并发的事务槽等待，事务槽的并发等待是由于索引分裂阻塞大量会话导致的并发加剧的问题，所以我们主要看索引分裂的问题。

通过ASH 信息进行分析，活动会话飙升时刻在18 点32 分，当时阻塞者一直是节点2 的8442 会话，随后被阻塞会话不断飙升，被阻塞会话都是在等待TX – index contention 索引分裂。

根据ASH 继续分析8442 这个会话的活动情况，可以看到8442 从18 点32 分开始一直到19 点32 分持续1 小时一直在执行一个update 语句，等待事件上看是在等待单块读。

计划上看这个语句执行计划没有发生改变，逻辑读明显增大，在IO上等待严重，执行次数为0

那么问题就比较明显了，8442 会话执行更新操作，由于该会话一直等待单块读，阻塞了大量会话去等待索引分裂，而实际上8442 正在执行的操作就是索引分裂，那么为什么索引分裂需要持续这么久，扫描这么多的单块读，下面我们在awr 中查看failed probes on index block reclamation 这个指标，总共出现105w 次，平均每秒1152 次

select 
    a.INSTANCE_NUMBER,
    a.BEGIN_INTERVAL_TIME,
    b.STAT_NAME,b.VALUE,
    b.value-lag(b.value,1)over(order by a.begin_interval_time) as intervalvalue
 from 
     dba_hist_snapshot a,
     DBA_HIST_SYSSTAT b 
 where 
     a.instance_number=2 
 and a.INSTANCE_NUMBER=b.INSTANCE_NUMBER 
 and a.SNAP_ID=b.SNAP_ID 
 and b.STAT_NAME='failed probes on index block reclamation' 
 and a.BEGIN_INTERVAL_TIME>sysdate-1 order by 2;

那么问题锁定到为什么会扫描大量块不可用呢，这种问题一般在两种场景较为突出

一种是插入的表正在执行批量DELETE 操作，DELETE 导致出现了大量的空块，但是空块上还存在着事务未提交，当索引分裂时这些被释放的空块会被扫描并检查，当发现上面还有事务没有提交时就会发生failed 。

另外一种是索引存在大量的碎片，段空间自动管理使用位图去管理段内的空闲空间，这些Free Block 的要求是status 是75%-100% Free 的， server process 会扫描这些75%-100% Free 的block 并确认这些block 实际上是100% 空的，如果找到100% Free Block 则使用；如果没有则继续搜索，直到所有候选block 都被检查过，这个行为叫做 probes on index block reclamation 。每次寻找空块并failed ，oracle 就会增加这个统计指标