DB2存储过程更新延迟求助：Cognos回写DB2表更新慢

针对你遇到的更新同一条记录后数据刷新延迟15-20分钟的问题，结合提供的存储过程代码，从DB2存储过程、表结构和Cognos配置三个方向给出优化建议：

一、存储过程代码优化 #

你的存储过程存在冗余且可能影响数据一致性的代码：

1. 移除无用游标
   代码中声明的游标e1固定查询job_status_summary_key=17076的记录，还使用WITH UR（未提交读）隔离级，这和更新逻辑完全无关，既浪费资源，还可能让Cognos读取到脏数据。建议改为返回更新操作的实际影响行数，或者直接移除动态结果集（如果不需要返回结果）：

   create procedure ngetl.new_update_comment (
           in @p_job_status_summary_key integer
           ,in @p_comment varchar(4000)
           ,in @p_modified_by varchar(25)
         )
       dynamic result sets 1
   begin
     declare v_update_count integer default 0;
     declare e1 cursor with return for
       select v_update_count as update_rows;
     
     if upper(@p_modified_by) like '%IBM%'
       or upper(@p_modified_by) like 'V%' then
       update ngetl.job_status_summary
         set ibm_comment = @p_comment
             ,modified_by_ibm = @p_modified_by
             ,timestamp_ibm = current_timestamp
         where job_status_summary_key = @p_job_status_summary_key;
       set v_update_count = @@ROWCOUNT; -- 获取更新行数
     else 
       update ngetl.job_status_summary
         set sbi_comment = @p_comment
             ,modified_by_sbi = @p_modified_by
         where job_status_summary_key = @p_job_status_summary_key;
       set v_update_count = @@ROWCOUNT;
     end if;
     commit;
     open e1;
   end
   

2. 确认事务提交逻辑
   现有代码更新后立即commit的逻辑是正确的，但要确保没有其他嵌套事务或未提交操作持有锁，导致数据无法及时刷新。

二、DB2表结构与性能优化 #

1. 检查索引是否存在
   确认job_status_summary表的job_status_summary_key字段是否为主键或创建了唯一索引。如果没有，更新操作会执行全表扫描，不仅速度慢还可能引发锁升级，延迟数据读取。创建索引的语句：

   create unique index idx_job_status_key on ngetl.job_status_summary(job_status_summary_key);
   

2. 排查锁等待问题
   使用db2pd -locks命令查看是否有长事务持有目标记录的锁，若存在可手动终止长时间未释放的事务，避免锁阻塞导致数据刷新延迟。

三、Cognos端缓存优化 #

更新后延迟显示最常见的原因是Cognos的报表缓存：

• 打开对应报表的属性设置，将缓存策略改为“不缓存”或设置极短的缓存过期时间（比如1分钟）；
• 在执行更新操作的Cognos动作流程中，添加“刷新报表”的步骤，强制从DB2读取最新数据。

验证步骤 #

1. 先修改存储过程，移除无用游标；
2. 确认job_status_summary_key的索引已创建；
3. 调整Cognos缓存设置；
4. 测试更新操作，观察数据刷新时间是否缩短。

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