ASH不直接标记索引分裂，而是通过buffer busy waits、RAC下的2-way争用、db file sequential read异常等运行时痕迹识别；需结合current_obj#、sql_id和ON CPU状态综合判断，且须验证是否真访问叶块。
ash 本身不直接标记“这是索引分裂”，但能抓到分裂引发的典型等待、访问模式和会话行为——关键不是找“分裂”这个词，而是识别它留下的运行时痕迹。
查不到 enq: TX - index contention 就说明没分裂？
错。这个事件只在右侧热点（如递增主键+高并发插入）导致 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' 看是否集中在索引维护路径上。
为什么 V$ACTIVE_SESSION_HISTORY 查不到最近的分裂线索？
常见原因有三个，且都和时间窗口与内存有关：
- 没加
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%，这才是分裂后空间未复用的铁证。
怎么把 ASH 数据和具体索引关联起来？
不能只靠 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+）还原上下文。
重建索引前，先跑 ALTER INDEX ... COALESCE 真的够用？
够用，但有条件：
- 只适用于叶块间存在相邻空闲空间可合并的情况（即
LF_ROWS少、DEL_LF_ROWS多、BLOCKS未显著增长） - 不锁整个索引，DML 可继续，但不会降低
BLEVEL，也不清理枝节点碎片 - 如果
INDEX_STATS.BLOCKS明显大于LF_BLKS，且BLKS_GETS_PER_ACCESS > 5，说明分裂已造成物理离散，COALESCE效果有限，得上REBUILD
真正容易被忽略的是：重建前必须确认该索引是否被 DBMS_SCHEDULER job 或后台批处理频繁调用——这些会话在 ASH 里表现为 program LIKE '%j00%'，若没停掉，REBUILD 会卡在 DDL lock 上，反过来又拖慢 job 执行。
