awr中判断enq: tx - row lock contention严重程度需看top 5事件中avg wait ms是否超10ms；重点分析time(s)和avg wait ms，结合segments by row lock waits、dba_hist_active_sess_history定位阻塞链，并区分主键冲突、行更新冲突及位图索引三类成因。
awr里怎么看enq: tx - row lock contention的严重程度
直接看awr报告中「top 5 timed foreground events」部分，如果enq: tx - row lock contention排进前5且平均等待时间（avg wait ms）超过10ms，基本可以判定是真实瓶颈，不是偶发抖动。
注意别只盯「Waits」列总数——它可能被长事务拉高，但实际业务影响小；重点看「Time(s)」和「Avg wait ms」：前者反映锁争用消耗的总数据库时间，后者暴露单次阻塞是否已影响交互响应。
- 如果Avg wait ms
- 若Avg wait ms > 50ms，说明持有锁的会话很可能在做DML后未提交，或存在应用层事务控制缺陷
- 检查「Background Wait Events」里有没有配套的
enq: TX - allocate ITL entry，有则暗示热点块ITL槽不足，和行锁争用常伴生
从AWR定位具体阻塞链：谁锁了谁、锁了多久
AWR本身不存完整阻塞快照，但可通过「Segment Statistics」→「Segments by Row Lock Waits」找到被争抢最狠的表和索引；再结合「SQL Statistics」→「SQL ordered by Gets」或「SQL ordered by Executions」，交叉筛选出高频更新同一张表的SQL。
更关键的是查DBA_HIST_ACTIVE_SESS_HISTORY视图（需有诊断包许可），用如下逻辑回溯：
SELECT sample_time, session_id, blocking_session, sql_id, event, p1text, p1 FROM dba_hist_active_sess_history WHERE event = 'enq: TX - row lock contention' AND sample_time > SYSDATE - 1/24 ORDER BY sample_time DESC;
其中p1是锁请求的mode+type编码，解码后能确认是S/X锁请求；配合blocking_session字段，可顺藤摸瓜查到持锁会话的sql_id和执行堆栈。
- 别依赖AWR报告里的「SQL ordered by Version Count」——它反映游标共享问题，和TX锁无关
- 如果
blocking_session为空，可能是自锁（如一个会话update后没commit又去update同一行），此时看session_id自身前后样本是否连续出现该event - 注意
sample_time精度是秒级，无法精确定位毫秒级阻塞起点，仅作趋势判断
enq: TX锁类型和常见误判场景
enq: TX本质是事务锁（Transaction enqueue），但触发原因有三类，必须区分清楚，否则优化方向全错：
- 主键/唯一键冲突：两个会话同时insert相同PK值，第二个会话等第一个rollback/commit——这不是“锁争用”，是约束校验机制，应查应用是否重复发ID或缺少前置select
- 行更新冲突：典型场景，会话A update某行未commit，会话B update同一行被阻塞——这是真TX锁争用，需查A的事务时长和SQL逻辑
- 位图索引更新：更新位图索引键值时，Oracle会对整个键范围加锁，极易引发大面积阻塞——若表有位图索引，先评估能否改用B树索引
验证方法：查v$lock中type='TX'记录的lmode和request。若request=6（X锁）且lmode=0，是纯等待；若lmode=6且request=0，是持锁方；若lmode=4（S锁）且request=6，极可能是唯一键冲突。
为什么加索引有时反而加重enq: TX争用
给经常被where条件扫描的列加索引，本意是减少全表扫描，但若该索引是高频DML的目标（比如status字段上的索引），会导致所有update都需维护这个索引分支，物理上把原本分散的行锁集中到少数几个索引块上，放大争用。
典型信号：AWR中「Segments by Row Lock Waits」里，锁等待集中在某个索引段（而非表段），且该索引列更新频繁。
- 检查索引是否被业务SQL的where/update set子句高频引用，尤其是低基数列（如status in (0,1,2)）
- 用
DBA_INDEXES查num_rows和clustering_factor，若clustering_factor接近表行数，说明索引顺序和表物理顺序严重偏离，维护成本高 - 考虑函数索引或分区索引替代，或者干脆去掉非必要索引——行锁争用比慢查询更致命
复杂点在于，同一个索引在OLTP场景可能是瓶颈，在报表场景却是加速器；没有全局最优解，得按具体SQL的执行频率、事务边界、数据分布来权衡。别迷信“有索引一定好”。
