ash可精准定位enq: tx - index contention的索引、会话及分裂类型，需筛选event、blocking_session、obj#等关键字段，并校验p3值区分于行锁争用。
直接看ash，别只盯awr的top events
awr里enq: tx - index contention排在前列，只能说明问题存在，但无法定位是哪个索引、哪个会话、哪类分裂在拖慢系统。ash（v$active_session_history）才是微观诊断的核心——它按秒采样，能抓到真实阻塞链。你得筛出event = 'enq: tx - index contention'的样本，再按blocking_session和sql_id下钻。
常见误操作是导出ASH后不做列裁剪，原始视图有40+列，真正有用的就SESSION_ID、SQL_ID、EVENT、BLOCKING_SESSION、OBJ#、TIME_WAITED这几个。漏掉OBJ#，你就没法反查是哪个索引段；漏掉TIME_WAITED，就分不清是偶发抖动还是持续卡顿。
从ASH里快速锁定分裂热点索引
OBJ#字段值对应dba_objects.object_id，但注意：它不直接等于索引名，需关联查询。执行以下语句可快速映射：
SELECT owner, object_name, object_type FROM dba_objects WHERE object_id IN ( SELECT DISTINCT obj# FROM v$active_session_history WHERE event = 'enq: TX - index contention' );
结果通常集中于1–3个索引，比如AATD_IDX4、A_DTL_PK这类全局索引。若发现多个索引同时上榜，大概率是同一张表的高并发DML引发的连锁分裂——此时要优先检查该表的INITRANS和索引PCTFREE设置。
- 90-10分裂主导：
OBJ#集中在最右叶块（如主键递增插入），SQL_ID多为INSERT INTO ... VALUES (seq.nextval, ...) - 50-50分裂主导：
OBJ#分散但重复出现，SQL_ID含UPDATE或非单调INSERT，常伴buffer busy waits
区分index contention和row lock contention的阻塞源头
这两个等待事件在ASH里字段高度相似，但enq: TX - row lock contention的P3值通常是0x0或小数值，而enq: TX - index contention的P3一定含0x2000000标志位。光看EVENT列容易误判——必须校验P3。
更关键的是阻塞关系：index contention的BLOCKING_SESSION往往指向一个正在做索引分裂的会话，该会话自身EVENT可能是db file sequential read（在找空块）或latch: cache buffers chains（在遍历buffer header）。而row lock contention的阻塞者通常EVENT是enq: TX - row lock contention本身，形成环状等待。
如果BLOCKING_SESSION为空，说明是自阻塞（比如单个会话触发根节点分裂），这时要查SQL_ID对应语句是否批量插入导致连续分裂。
重建索引前先确认分裂类型和影响范围
不要一看到enq: TX - index contention就急着ALTER INDEX ... REBUILD ONLINE。先查v$sysstat确认分裂规模：
SELECT name, value
FROM v$sysstat
WHERE name IN ('leaf node splits', 'leaf node 90-10 splits');
若leaf node splits总量大但90-10 splits占比超80%，说明是单调主键场景，反向键索引（REVERSE）比哈希分区更合适；若50-50分裂占多数，且业务SQL大量用WHERE col BETWEEN ? AND ?，则哈希分区可能破坏范围扫描，得权衡。
重建前务必检查索引是否被NOLOGGING操作污染过——DBA_INDEXES.logging = 'NO'时，REBUILD ONLINE仍会生成大量redo，可能触发log file sync连锁等待。这种情况下，先ALTER INDEX ... LOGGING再重建更稳妥。
最易被忽略的一点：全局索引在分区表TRUNCATE PARTITION后不会自动维护，残留的“幽灵条目”会导致后续DML频繁分裂。ASH里若看到OBJ#对应索引名带_GLO后缀，且SQL_ID含UPDATE INDEXES，基本可断定是这个原因。
