求助解决DB2争用问题：分布式线程引发性能下降与系统中断

• 精准定位争用资源
  先通过DB2工具明确具体争用对象：

  • 执行db2pd -locks查看锁持有与等待状态，重点筛选类型为DIST的分布式线程，确认其持有的锁类型（行锁/表锁）、关联对象ID
  • 用db2mon -d <数据库名> -u监控分布式事务的ID、锁等待时长，关联到对应存储过程和批处理作业

• 调整分布式线程隔离级别
  分布式存储过程默认隔离级别（如RR/RS）易引发长期锁持有：

  • 将存储过程隔离级别改为CS（游标稳定性）或UR（未提交读，仅适用于非敏感只读场景），修改示例：

    ALTER PROCEDURE <存储过程名> SET OPTION ISOLATION CS;
    

  • 确保分布式事务仅在必要操作阶段持有锁，避免跨节点冗余数据操作

• 优化批处理事务提交粒度
  细化已配置的提交策略，减少锁覆盖范围：

  • 将大事务拆分为小批次提交，例如每处理1000条记录执行一次COMMIT，避免一次性锁定大量数据
  • 检查批处理是否使用WITH HOLD游标，此类游标会在提交后保持锁持有，按需关闭或替换为普通游标

• 收紧存储过程事务边界
  严格控制分布式存储过程的事务范围：

  • 确保存储过程内事务仅覆盖核心操作，避免外层嵌套不必要的分布式事务
  • 只读型存储过程添加READ ONLY属性，降低锁资源消耗：

    CREATE OR REPLACE PROCEDURE <存储过程名> (...)
    READ ONLY
    LANGUAGE SQL
    BEGIN
      -- 业务逻辑
    END;
    

• DB2核心参数调优
  针对锁资源配置调整：

  • 设置LOCKTIMEOUT参数，避免线程无限期等待锁：

    UPDATE DATABASE CONFIGURATION FOR <数据库名> USING LOCKTIMEOUT 30;
    

  • 增大MAXLOCKS和LOCKLIST参数，防止锁升级（行锁→表锁）：

    UPDATE DATABASE CONFIGURATION FOR <数据库名> USING MAXLOCKS 20 LOCKLIST 4096;
    

• 资源隔离调度
  物理隔离争用资源：

  • 将批处理作业调度在分布式请求低峰时段执行
  • 对高频争用表采用分区设计，让批处理与分布式线程访问不同分区，减少锁冲突

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