数据库会话突然卡住不动，等待事件里冒出一串enq: TX - row lock contention，这种场面很多DBA都遇到过。enqueue锁机制是Oracle并发控制的核心基石，它不像latch那样只是短暂地保护内存数据结构，而是能够持续持有较长时间，用于管理用户对象和事务之间的资源协调。理解enqueue锁的类型以及它们对应的等待事件，是分析数据库性能瓶颈时绕不开的一环。
enqueue锁的本质与队列机制
enqueue这个词直译过来就是入队，它是一种带有队列性质的锁。Oracle通过一个简单的队列结构来管理锁请求，每个会话在请求锁时，如果资源已经被其他会话以不兼容的模式占用，那么这个会话就会被放入等待队列，直到资源释放。这种设计保证了多个会话之间的有序访问，避免出现死锁或资源永远无法释放的情况。
从底层实现来看，enqueue锁通过一个锁描述符保存在系统全局区中，每个锁都有一个资源结构，资源结构上挂着持有者和等待者的列表。当会话执行DML操作时，比如update或者delete，通常需要获取TX锁；而修改表结构或执行DDL时，则要获取TM锁。不同类型锁之间存在不同的兼容性矩阵，比如两个TX锁之间是兼容的，因为不同事务修改不同行互不影响；但如果两个事务要修改同一行，那么第二个事务就会陷入等待。
enqueue锁与latch最直观的区别在于持有时间和等待方式。latch的等待通常只有微秒级别，CPU自旋后立即重试；而enqueue锁的等待可能持续数秒甚至数分钟，需要主动释放CPU，并让出调度。在数据库等待事件中，enqueue相关的等待事件通常以enq开头，后面跟着锁类型和具体原因，例如enq: TX - row lock contention。
常见enqueue锁类型：TX、TM、UL
Oracle的enqueue锁有多种不同类型，每个类型用一个字母或组合表示。日常运维中最常遇到的是TX锁，也就是事务锁。当一个事务修改表中的数据时，会在修改行的行头上记录一个指向事务槽的指针，事务本身会持有一个TX锁。TX锁既用于保护事务本身，也用于标记被修改的行。如果两个并发事务尝试修改同一行，那么后一个事务就会被阻塞，等待前一个事务提交或回滚。
TM锁是表级锁，用于确保表结构在DML操作期间不被修改。比如一个会话正在update某张表，另一个会话执行drop table或truncate table，这个DDL操作必须要获取排他模式的TM锁，但获取不到，因为先前的DML已经持有该表的行级别的TM锁，于是DDL就会阻塞。TM锁的持有时间通常很短，但如果事务特别长，或者存在未提交的DDL，也会引发等待事件enq: TM - contention。
UL锁是用户自定义锁，通过dbms_lock包创建的锁也属于enqueue机制。这类锁在应用层实现业务串行化时非常有用，但使用不当很容易造成莫名等待。比如在代码中请求一个UL锁之后忘了释放，后续所有需要该锁的会话都会永久阻塞。在等待事件中，enq: UL - contention往往与用户自定义锁相关，需要结合应用逻辑判断。
高频enqueue等待事件详解
enq: TX - row lock contention是所有enqueue等待事件中出现频率最高的一种。它的本质是多个会话争抢同一行数据。当一个会话更新了某一行但尚未提交，另一个会话也想更新这一行，此时后者就会进入该等待事件。要解决这种竞争，首先需要检查被阻塞的会话对应的v$lock表中blocking_session字段，找到谁持有锁。阻塞者可能在执行一个特别长的事务，也可能只是网络闪断或程序异常导致事务迟迟没有结束。
另一种容易混淆的等待是enq: TX - allocate ITL entry。这种等待与Oracle的块内部空闲事务槽有关。如果一个数据库块被多个并发事务修改，而块上的ITL槽位数量不够，就会导致需要分配新ITL槽的会话等待。解决办法通常包括两种情况：一是增加表的initrans参数，让块初始拥有更多ITL槽，二是检查是否存在大量并发更新同一表的同一批数据块，尝试优化业务逻辑或使用更小的块大小。
还有一类常见等待是enq: TX - index contention，这通常出现在高并发的批量insert操作中，所有会话都在往同一索引的叶子块插入新的键值。特别是使用单调递增的序列作为主键时，所有插入都在同一个索引块的右侧进行，容易引发争用。优化方式可以改为使用反向索引，打散键值的分布，或者采用分区表把数据分散到不同分区，降低索引块的热点问题。
-- 查看当前阻塞链：找出锁源和被阻塞的会话
SELECT
blocking_session,
sid,
serial#,
wait_event_text,
seconds_in_wait
FROM
v$session
WHERE
type = 'USER'
AND blocking_session IS NOT NULL
ORDER BY
blocking_session;
-- 查看特定锁的持有者和等待者详情
SELECT
l1.sid AS holder_sid,
l2.sid AS waiter_sid,
l1.type AS lock_type,
l1.lmode,
l2.request
FROM
v$lock l1
JOIN v$lock l2 ON l1.id1 = l2.id1 AND l1.id2 = l2.id2
WHERE
l1.block = 1
AND l2.request > 0;
定位enqueue等待问题的标准步骤
当数据库出现大量enqueue等待时，不要盲目杀掉会话，应该按照一套标准流程来排查。第一步通过v$session视图确认具体是哪个enqueue类型和模式，记录wait_class。第二步使用v$lock的block列，找出阻塞链的源头。第三步查看阻塞会话的当前执行的SQL，以及它的状态。如果阻塞会话状态是inactive，说明它可能已经完成操作但事务没有提交，可以考虑终止该会话；如果状态是active，则要在内部进一步分析。
在分析事务锁等待时，awr报告中的enqueue活动部分也能提供有价值的参考，可以看到Top 5等待事件里enqueue的类型和占比。如果等待集中在TX row lock contention，还需要结合v$sqlarea查看是否存在针对同一行的高频update语句。此时往往要从业务层面入手，例如减少长事务的持有时间，把大事务拆分为多个小事务，或者引入重试机制避免并发冲突。
对于TM锁争用，重点检查是否有DDL操作阻塞了DML。这种问题往往出现在业务高峰期的对象重建操作上。建议将DDL操作安排在低峰期，或者使用ONLINE关键字重建索引。同时也可以监控v$session_longops，观察DDL操作的进度。
-- 查询当前正在等待enqueue锁的会话详细信息
SELECT
s.sid,
s.serial#,
s.username,
s.status,
s.blocking_session,
s.event,
s.seconds_in_wait,
q.sql_text
FROM
v$session s
LEFT JOIN v$sql q ON s.sql_id = q.sql_id
WHERE
s.event LIKE 'enq: %'
AND s.type = 'USER';
-- 根据阻塞会话的SID执行该语句（慎用），可终止会话
-- ALTER SYSTEM KILL SESSION '123,456' IMMEDIATE;
常用调优思路与预防措施
针对不同的enqueue等待事件，调优手段差异很大。行锁竞争的本质是业务并发冲突，最有效的办法是减少并发争抢同一行的概率。比如在电商系统中，多个订单操作同时更新同一个库存商品的库存量，就会形成热点行。此时可以把库存拆分成多份，用类似分桶的方式分散到不同的行里，然后把所有桶的数值汇总作为总库存。
对于ITL不足产生的等待，可以在创建表时通过initrans参数增加初始ITL槽数。不过要注意，增大initrans会稍微增加数据块头部的开销，如果块内可用空间变小，反而可能触发行迁移。更合理的做法是合理控制块大小和pctfree，并在高并发场景下对表进行监控，观察实际ITL使用情况。
索引冲突型的等待，则要从索引设计入手。如果主键值单调递增，可以考虑使用哈希索引替代B树索引。但Oracle默认的索引就是B树，想要打散分布可以借助虚拟列或反转键。另外，使用索引组织表也可能因为键值顺序导致写入热点，对这些情况则需要仔细权衡。
最后，不要忘了定期采集性能基线数据。建立enqueue等待事件的历史时长和次数指标，当发现等待时间出现明显增长时，可以提前介入，而不是等到应用严重变慢时才处理。
Oracle enqueue锁等待事件TX锁修改时间：2026-08-19 10:34:43