请求验证DB2自增序号存储过程并排查SQL0913(-913)执行错误

AI 小北

2026-7-31

存储过程代码验证与优化

你编写的存储过程逻辑上能实现序号自增，但存在几个关键问题：

全表锁导致并发瓶颈：LOCK TABLE ... IN EXCLUSIVE MODE会锁定整个表，任何其他访问该表的请求都会被阻塞，高并发场景下会频繁出现锁冲突。
未处理记录不存在的情况：如果TYPE对应的记录不存在，SELECT R08NRO返回NULL，后续OPERATION_NUMBER +1会得到NULL，最终更新后的值也是NULL，导致逻辑错误。
冗余配置：DYNAMIC RESULT SETS 1声明会返回1个结果集，但存储过程仅使用输出参数，无结果集返回，该配置可改为DYNAMIC RESULT SETS 0或直接删除。

优化后的存储过程（原子性+行级锁+空值处理）：

CREATE OR REPLACE PROCEDURE GET_NEXT_OPERATION_NUMBER (
        IN TYPE INTEGER,
        OUT OPERATION_NUMBER INTEGER
)
    LANGUAGE SQL 
    NOT DETERMINISTIC 
    MODIFIES SQL DATA 
    CALLED ON NULL INPUT 
    SET OPTION  ALWBLK = *ALLREAD , 
    ALWCPYDTA = *OPTIMIZE , 
    COMMIT = *CS , 
    DECRESULT = (31, 31, 00) , 
    DFTRDBCOL = *NONE , 
    DYNDFTCOL = *NO , 
    DYNUSRPRF = *USER , 
    SRTSEQ = *HEX 
P1: BEGIN
    -- 用MERGE原子完成查询、更新/插入，自动行级锁，处理无记录场景
    MERGE INTO SMPORDD.R08FNTR AS T
    USING (SELECT TYPE AS R08IDT FROM SYSIBM.SYSDUMMY1) AS S
    ON T.R08IDT = S.R08IDT
    WHEN MATCHED THEN
        UPDATE SET T.R08NRO = T.R08NRO + 1
        RETURNING T.R08NRO INTO OPERATION_NUMBER
    WHEN NOT MATCHED THEN
        INSERT (R08IDT, R08NRO) VALUES (S.R08IDT, 1)
        RETURNING R08NRO INTO OPERATION_NUMBER;
        
    COMMIT;
END P1

SQL0913（-913）错误排查解决

错误提示表被占用，本质是锁冲突：你的存储过程请求全表排他锁时，该表已被其他会话持有冲突锁（共享锁、其他排他锁），导致请求被阻塞或直接报错。

解决步骤：

定位锁持有者：
- 在IBM i终端执行命令：WRKOBJLCK OBJ(SMPORDD/R08FNTR) OBJTYPE(*FILE)，查看哪些会话持有该表的锁。
- 或用SQL查询锁信息：
```
SELECT LOCK_OWNER, LOCK_MODE, LOCK_STATUS 
FROM QSYS2.SYSLICKS 
WHERE LOCK_OBJECT_NAME = 'R08FNTR' 
  AND LOCK_SCHEMA_NAME = 'SMPORDD';
```
替换全表锁为行级锁：使用上面优化后的MERGE语句，DB2会自动对目标行加锁，不影响其他行的操作，从根本上减少锁冲突。
检查JPA事务配置：确认Java端调用存储过程时的事务是否正确提交，是否存在未关闭的长事务持有表锁。比如检查@Transactional注解的传播行为、是否有未提交的事务在操作该表。
缩短事务时长：所有操作该表的事务都要尽快提交，减少锁持有时间，降低冲突概率。
可选：设置锁等待超时：如果必须保留表锁，可在存储过程开头添加SET LOCK TIMEOUT 60;（等待60秒），但这只是缓解手段，不是最优解。

内容的提问来源于stack exchange，提问作者ca_san_sal