怎样在Oracle 12c中使用ASH分析索引分裂导致的性能延迟

作者：袖梨 2026-06-23

ASH不直接标记索引分裂，而是通过buffer busy waits、RAC下的2-way争用、db file sequential read异常等运行时痕迹识别；需结合current_obj#、sql_id和ON CPU状态综合判断，且须验证是否真访问叶块。

ash 本身不直接标记“这是索引分裂”，但能抓到分裂引发的典型等待、访问模式和会话行为——关键不是找“分裂”这个词，而是识别它留下的运行时痕迹。

错。这个事件只在右侧热点（如递增主键+高并发插入）导致 ITL 争用时才高频出现，但很多分裂根本不会触发它。更常见的信号是：

buffer busy waits：尤其集中在索引段头块或叶块，说明多个会话争抢同一块做分裂前的 pin/unpin
gc current block 2-way（RAC 环境）：分裂后新右块物理位置分散，跨节点读取增多
db file sequential read 伴随高 BLKS_GETS_PER_ACCESS：范围扫描本该顺序读 10 块，实际逻辑读 15 块以上，说明叶块物理不连续

别只盯着一个 event，要组合 current_obj#（对应索引对象 ID）、sql_id 和 session_state = 'ON CPU' 看是否集中在索引维护路径上。

常见原因有三个，且都和时间窗口与内存有关：

没加 WHERE sample_time > SYSDATE - 1/1440（过去 1 分钟）：ASH 默认保留约 1 小时，但高负载下缓冲区满得快，不加过滤容易扫到被覆盖的老数据
_ash_size 太小（默认 4MB）：查 SELECT * FROM v$sgastat WHERE name LIKE '%ASH%'，如果 bytes 长期低于 10MB，采样丢失率就很高
分裂发生太快、太短：比如单次 90-10 分裂只耗几毫秒，而 ASH 是每秒采样一次，很可能错过

这时得退一步，用 ANALYZE INDEX ... VALIDATE STRUCTURE 查 INDEX_STATS，看 DEL_LF_ROWS_LEN / LF_ROWS_LEN 是否 >20%，这才是分裂后空间未复用的铁证。

不能只靠 current_obj# 对应到索引名就结束，必须验证访问是否真落在叶块上：

先查出可疑 sql_id 涉及的表和索引：SELECT object_name, object_type FROM dba_objects WHERE object_id IN (SELECT current_obj# FROM v$active_session_history WHERE sql_id = '84m7xzxz0181g' AND sample_time > SYSDATE - 1/24 GROUP BY current_obj#)
再确认该索引是否正在被 DML 访问：SELECT index_name, monitoring FROM dba_indexes WHERE table_name = 'YOUR_TABLE'；若 monitoring = 'YES'，说明近期有大量更新
最后看执行计划里是否用了该索引的 RANGE SCAN 或 FAST FULL SCAN，并检查 access_predicates 是否因绑定变量值倾斜导致反复分裂

注意：V$ACTIVE_SESSION_HISTORY 中的 sql_id 可能已不在 V$SQL 里，优先查 DBA_HIST_SQLTEXT 或用 DBMS_XPLAN.DISPLAY_ASH（12c+）还原上下文。

够用，但有条件：

只适用于叶块间存在相邻空闲空间可合并的情况（即 LF_ROWS 少、DEL_LF_ROWS 多、BLOCKS 未显著增长）
不锁整个索引，DML 可继续，但不会降低 BLEVEL，也不清理枝节点碎片
如果 INDEX_STATS.BLOCKS 明显大于 LF_BLKS，且 BLKS_GETS_PER_ACCESS > 5，说明分裂已造成物理离散，COALESCE 效果有限，得上 REBUILD