ENQUEUE_LOCKS是Oracle数据库中一个非常典型又容易被忽视的初始化参数。它定义了实例启动时预分配的队列锁资源的最大数量，也就是数据库内部可以同时持有的enqueue结构总数。很多DBA在平时接触不到它，因为默认值通常够用，可一旦系统并发量上来，或者执行大批量DML、并行DDL操作时，就可能出现锁资源不足的报错，这时候才不得不去研究这个参数。理解它的含义和工作机制，对排查锁相关的数据库故障非常有帮助。
ENQUEUE_LOCKS参数的底层含义
要理解ENQUEUE_LOCKS，首先要明白什么是enqueue。在Oracle中，enqueue是一种比行级锁更底层的串行化机制，数据库用队列的方式管理对各种资源的并发访问。这些资源包括表（TM锁）、事务（TX锁）、备份操作、并行查询、库缓存对象等几十种类型。每一个被持有的enqueue都会占用一个锁结构，而这个结构就来自ENQUEUE_LOCKS所定义的内存池。
可以把它简单理解为系统全局的“锁槽位”数量。参数值越大，实例能同时维护的锁结构就越多，相应的内存开销也会增加。每个锁结构占用的内存并不大，但它属于SGA中的固定分配部分，实例启动时就会预留出来，运行期间不会动态扩展。所以如果设置得太小，高并发场景下会直接报错；设置得过大，虽然不会出错，但会浪费内存。
查看当前值的命令很简单：
-- 查看当前实例的ENQUEUE_LOCKS设置 SHOW PARAMETER enqueue_locks; -- 或者通过视图查询 SELECT a.ksppinm AS parameter_name, b.ksppstvl AS value FROM x$ksppi a, x$ksppcv b WHERE a.indx = b.indx AND a.ksppinm = '_enqueue_locks';
需要注意的是，在较新版本的Oracle中，ENQUEUE_LOCKS默认作为隐藏参数_enqueue_locks的对外暴露形式存在，普通视图里能看到它的值，但如果要修改，通常需要一定的权限，并且修改后需要重启实例才能生效。
默认值是如何计算的
ENQUEUE_LOCKS是一个典型的大小自适应参数。如果没有显式指定，Oracle会根据SESSIONS参数的值自动推导出一个合理的默认值。基本规则是：默认值取SESSIONS值乘以一个系数，在大多数版本中这个系数约为1.1到1.25之间，并且有一个最低保底值。例如SESSIONS设置为170，那么ENQUEUE_LOCKS大约会是2000以上，保证每个会话至少能持有若干个锁结构。
这个推导机制带来一个很重要的推论：当你调大SESSIONS以支撑更多并发连接时，ENQUEUE_LOCKS往往也会跟着水涨船高，所以单纯增加会话数的场景一般不需要单独动它。真正需要手动干预的情况是：单个会话持有锁的数量异常庞大，典型的例子是某些批量处理程序在一个事务里更新了几十万行数据，同时操作了大量的分区表或者触发了大量的递归锁请求。
判断当前锁资源是否紧张，可以观察V$RESOURCE_LIMIT视图：
-- 查看enqueue资源的当前使用情况
SELECT resource_name, current_utilization, max_utilization,
initial_allocation, limit_value
FROM v$resource_limit
WHERE resource_name IN ('enqueue_locks', 'enqueue_resources');
-- 关注current_utilization是否接近initial_allocation
-- max_utilization记录了历史峰值，是容量评估的重要依据如果max_utilization已经非常接近initial_allocation，说明系统曾经逼近上限，存在隐患，此时就应该考虑扩容了。
与DML_LOCKS等参数的区别
很多人容易把ENQUEUE_LOCKS和DML_LOCKS搞混。DML_LOCKS控制的是TM类型锁的数量，也就是针对表级DML操作的锁，范围比较窄。而ENQUEUE_LOCKS是一个更上层的总量控制，涵盖所有类型的队列锁，包括事务锁、DDL锁以及各种内部机制使用的锁。可以粗略认为DML_LOCKS是ENQUEUE_LOCKS预算中的一部分。
此外还有ENQUEUE_RESOURCES这个概念，在老版本Oracle中它是独立参数，控制锁资源表的大小；在新版本中它已经逐渐被并入统一的管理框架。三者的关系可以这样概括：ENQUEUE_RESOURCES定义资源对象本身的数量，DML_LOCKS定义其中表锁的部分，ENQUEUE_LOCKS则定义整体锁结构的容量上限。
下面用一个简单的对比表说明它们各自的作用范围：
| 参数 | 控制范围 | 是否需要重启 |
|---|---|---|
| ENQUEUE_LOCKS | 所有队列锁结构的总量 | 是 |
| DML_LOCKS | 表级TM锁数量 | 是 |
| ENQUEUE_RESOURCES | 锁资源对象数量（旧版本） | 是 |
锁资源不足的报错与处理
当ENQUEUE_LOCKS耗尽时，常见的报错是ORA-00063或者提示超出enqueue资源上限的信息，具体报错号因版本和场景而异。表现通常是：业务在某个时间点突然大量会话挂起，alert日志中出现相关告警，等到锁资源释放后才恢复正常。这种故障具有明显的突发性，排查时一定要结合V$RESOURCE_LIMIT的历史峰值来判断。
处理思路分两步。第一步是确认根因，用下面的SQL找出持有锁最多的会话，判断是正常业务量增长还是异常代码导致：
-- 统计每个会话持有的enqueue数量，找出大户 SELECT sid, count(*) AS lock_count FROM v$lock GROUP BY sid ORDER BY lock_count DESC FETCH FIRST 10 ROWS ONLY;
第二步才是调整参数。修改方式是在spfile中设置新值然后重启：
-- 修改参数（需要重启实例生效） ALTER SYSTEM SET enqueue_locks = 20000 SCOPE = SPFILE; -- 重启后验证 SHOW PARAMETER enqueue_locks;
建议调整时参考max_utilization的值，在峰值基础上预留至少百分之五十的余量。如果发现是单个事务持有几十万锁结构，更应该先从应用层面优化入手，比如拆分大事务，而不是一味调大参数，因为过大的事务本身就是性能隐患。
生产环境配置建议
对于绝大多数OLTP系统，ENQUEUE_LOCKS保持默认值即可，Oracle的自适应推导机制已经考虑得比较周全。需要主动关注的场景主要有三类：数据仓库类的批量加载作业、使用大量分区且涉及多分区DML的表、以及频繁使用并行DDL的维护窗口。
运维实践中建议把V$RESOURCE_LIMIT的监控纳入日常巡检，重点跟踪max_utilization与initial_allocation的比值。当比值超过百分之七十时就应该评估扩容，超过百分之九十则属于高危状态。同时要注意，每次调整SESSIONS参数后，都应该重新核对ENQUEUE_LOCKS的推导值是否仍然满足需求，避免因为连带关系没理清而埋下隐患。
最后提醒一点，修改这类需要重启的静态参数一定要走规范的变更流程，选择业务低峰期执行，并在变更前对spfile做好备份。锁参数虽然不起眼，但一旦出问题往往影响面很大，提前规划远比事后救火划算。
ENQUEUE_LOCKSOracle参数队列锁修改时间：2026-09-15 04:44:37