当DB2数据库报出SQLCODE -904时，通常表示请求的资源暂时不可用。如果错误信息中的原因码与锁定相关，例如提示锁等待超时或锁资源不满足，说明当前事务在竞争同一批数据页、行或表时已经超出了数据库允许的等待时间。这时应用侧通常会看到事务回滚或批量任务中断，开发人员需要同时检查会话状态、锁链关系和事务执行逻辑才能找到根因。
一、先理解SQLCODE -904与锁超时的触发条件
DB2中的锁用于保证事务隔离，防止多个会话同时修改同一数据导致脏读、不可重复读或丢失更新。当一个会话持有行级或表级锁，另一个会话需要访问同一资源但请求的锁模式不兼容时，就会进入锁等待队列。如果等待时间超过LOCKTIMEOUT设定值，或者触发资源不可用原因码，会话就会抛出SQLCODE -904。与其他常见错误相比，SQLCODE -911会回滚当前事务并返回死锁或锁超时，SQLCODE -913通常表示读取到未提交数据冲突，而SQLCODE -904更偏向资源本身暂时无法满足，原因码可以帮助判断是否属于锁等待场景。
因此处理SQLCODE -904不能只根据错误码判断，必须查看完整错误文本中的原因码和资源类型。DB2的诊断日志db2diag.log中通常会记录发生锁超时时的应用句柄、表名、请求的锁模式和已持有锁的句柄。先拿到这些信息，后续的定位才不会盲目。部分版本中与锁等待超时相关的原因码可能表现为00C90096，但这个值需要在具体环境中核对。实际排障时建议同时保留错误发生时间点，方便与快照和日志进行对照。
另外一个常见误区是把锁超时直接归为数据库参数太小。LOCKTIMEOUT设置较短可以更快暴露冲突，但增大它只是延长等待时间，并不能减少阻塞，甚至可能让前端响应更慢。真正需要做的是找到锁的持有者，确认它为什么没有及时提交或释放锁。
二、使用监视表函数定位锁等待链
定位锁等待的第一步是查看当前哪些会话正处于锁等待状态。DB2提供了SYSIBMADM.MON_LOCKWAITS视图和MON_GET_APPL_LOCKWAIT表函数，可以返回等待者的应用句柄、等待开始时间、已等待时长、请求的对象名以及当前持有锁的会话句柄。下面这条SQL按等待时间倒序输出当前锁等待信息。
SELECT APPLICATION_HANDLE, COORD_MEMBER, LOCK_WAIT_START_TIME, LOCK_WAIT_ELAPSED_TIME, LOCK_OBJECT_TYPE, TABSCHEMA, TABNAME, APPLICATION_HANDLE_HOLDING_LOCK FROM TABLE(MON_GET_APPL_LOCKWAIT(NULL, NULL)) AS L ORDER BY LOCK_WAIT_ELAPSED_TIME DESC;
APPLICATION_HANDLE字段表示正在等待锁的会话，APPLICATION_HANDLE_HOLDING_LOCK字段表示当前持有冲突锁的会话，TABSCHEMA和TABNAME则指出冲突发生在哪张表。拿到持有锁的句柄后，再查询该句柄正在执行的SQL和事务状态，确认它为什么长时间未提交。
SELECT APPLICATION_HANDLE, APPLICATION_NAME, CLIENT_HOST, CLIENT_PID, CURRENT_ACTIVITY, ROWS_READ, ROWS_RETURNED, STMT_TEXT FROM SYSIBMADM.MON_CURRENT_SQL WHERE APPLICATION_HANDLE = 12345;
上述SQL中的12345需要替换为从锁等待视图中查到的持锁句柄。STMT_TEXT显示该会话当前正在执行或最近执行的SQL语句，如果查询逻辑简单但返回行数很大，很可能就是缺少索引导致的扫描锁升级。也可以进一步查询当前锁列表，确认持锁的粒度是表级还是行级。
SELECT APPLICATION_HANDLE, LOCK_OBJECT_TYPE, TABSCHEMA, TABNAME, LOCK_MODE, LOCK_STATUS FROM TABLE(MON_GET_LOCKS(NULL, NULL)) AS L WHERE L.TABNAME = 'ORDER_MAIN' ORDER BY L.APPLICATION_HANDLE;
通过这三类信息，基本可以还原一个完整的锁等待链：某个批量任务持有ORDER_MAIN表的行级排他锁，但事务一直未提交；另一个在线请求试图更新同一批行，于是进入等待队列；当等待时间超过数据库配置后，在线请求抛出SQLCODE -904。定位到这一步，问题就从数据库错误变成了事务和SQL层面的阻塞。
三、从应用事务和SQL设计上消除阻塞
锁超时最常见的原因是事务持有锁的时间过长。典型场景包括：在事务中调用远程服务或外部接口、在循环里逐条执行更新但从不提交、把用户交互逻辑放进同一个事务等。解决方式是尽量缩短事务边界，把读取、计算、远程调用和最终更新拆开，只在真正需要保证原子性的地方开启数据库事务，处理完成后立即提交。
如果应用使用Java和JDBC，通常需要检查代码中是否在循环内执行update且循环结束后才提交。下面这段伪代码演示了反例与正确做法。
// 错误示例：整个循环使用同一个事务，锁持有时间过长
conn.setAutoCommit(false);
for (Order order : orderList) {
ps.executeUpdate(order);
}
conn.commit();
// 推荐做法：按批提交或逐条提交，缩短锁持有时间
conn.setAutoCommit(false);
int count = 0;
for (Order order : orderList) {
ps.executeUpdate(order);
count++;
if (count % 200 == 0) {
conn.commit();
}
}
conn.commit();
此外，批量更新顺序不一致也容易造成会话之间互相等待，甚至升级为死锁。如果两个批量任务都更新同一批表，但没有按照相同顺序处理，就可能出现A持有订单表锁等待明细表锁，B持有明细表锁等待订单表锁。统一更新顺序，或者对批量任务做串行化调度，能够显著减少这种冲突。
SQL层面则需要检查是否走了合适的索引。很多锁超时最终追溯到的SQL都包含大规模表扫描，数据库为了维护一致性会申请更多锁或直接进行锁升级，使并发事务的冲突面变大。通过EXPLAIN查看执行计划，为WHERE条件列和关联列补齐索引，把扫描行数从百万级降到百级，锁冲突概率通常会同步下降。
四、数据库参数调整与监控预防
数据库参数调整可以作为辅助手段，但不应该替代应用层修复。可以查看LOCKTIMEOUT参数值，默认情况下它可能设置为-1，表示不限制锁等待时间。将LOCKTIMEOUT设置成一个合理的有限值，例如30秒，可以避免一个会话无限等待，同时让锁冲突及时暴露。修改数据库级参数的示例SQL如下。
UPDATE DB CFG USING LOCKTIMEOUT 30 IMMEDIATE;
行级连接也可以使用CURRENT LOCK TIMEOUT特殊寄存器进行会话级设置，这样只对特定应用生效，不需要影响整个数据库。
SET CURRENT LOCK TIMEOUT = 20;
如果SQLCODE -904伴随频繁的锁升级，还可以检查LOCKLIST和MAXLOCKS参数。LOCKLIST决定锁列表内存大小，MAXLOCKS决定单个应用在锁列表中的最大使用比例。当超过MAXLOCKS时DB2会进行锁升级，把行锁升级为表锁，进一步阻塞其他会话。适当增大这两个参数，让行锁和页锁有足够内存空间，能够降低锁升级带来的冲突，但调整前需要评估数据库内存可用量。
UPDATE DB CFG USING LOCKLIST 4096 MAXLOCKS 50 IMMEDIATE;
在监控预防方面，可以开启锁定事件监视器，记录锁等待和死锁事件。例如创建锁定事件监视器后，当发生锁超时或死锁时，能够自动收集相关会话、SQL文本和锁信息，不需要问题复现时再手工查询。同时定期分析SYSIBMADM.MON_LOCKWAITS和MON_CURRENT_SQL中的长事务，对执行时间超过阈值的事务做告警，能够在大量SQLCODE -904出现前就发现异常持锁。
DB2 SQLCODE -904锁超时锁等待定位修改时间：2026-08-24 08:28:10