某日一直运行比较正常的报表系统，突然报存储过程执行失败，查看DB2 错误返回码为sql501n，查看此错误原因如下：

[db2inst1@limt ~]$ db2 ? sql501n



SQL0501N  The cursor specified in a FETCH statement or CLOSE statement

      is not open or a cursor variable in a cursor scalar function

      reference is not open.

Explanation: 

The program attempted to do one of:



*  FETCH using a cursor at a time when the specified cursor was not

   open.

*  CLOSE a cursor at a time when the specified cursor was not open.

*  Reference a cursor variable in an OPEN statement and the cursor

   variable is not open.

*  Reference a cursor scalar function, such as CURSOR_ROWCOUNT function,

   and the cursor variable is not open.

通过上述描述可以看出程序在FETCH 或者CLOSE 游标的时候，游标没有打开。

随后导出存储过程源码查看，此存储过程特点如下：

1 存储过程结构比较清晰，代码比较简单，在存储过程中调用了另一个存储过程

2 在存储过程中打开了一个游标，并且在代码后面也CLOSE了游标，在FETCH阶段也没有提前CLOSE游标

3 在嵌套的存储过程中也打开了游标，并且合理的关闭了游标

4 在嵌套的存储过程中也没有COMMIT操作（任何一个commit操作会导致所有的游标被关闭）





从代码上看不出来问题，那么回到系统整体上来分析：

1 此存储过程每天执行一次，以前从来没失败过

2 目前也不是每天都失败，偶尔也有成功的时候

3 每次失败的时候，在重新执行一次必然成功

4 此数据库前几天刚从V9.5.0.5升级到V9.5.0.10（V9.5.0.5 在linux系统上有内存泄露，导致SWAP空间被耗尽）





从上面两方面分析可以基本确定两点：





1 应该不是代码问题，如果是游标使用不当，那么为什么第二次调用就会成功

2 应该是数据库版本升级导致的存储过程执行错误，在数据库升级之前从来没失败过 





那么怎么解决这个问题，不可能回退到V9.5.0.5版本，初步分析可能是V9.5.0.10对游标使用发生了某些变化，

随后做了一下两个尝试：

1 重新rebind存储过程 db2 rebind xxxx,在做完此操作后，刚好遇到十一长假，竟然连续十几天没有报错，以为问题解决了，可是没过几天就

又开始报错了，看来问题没有解决；

2 然后就在网上百度，资料甚少，看来用DB2人还是太少了，点了几个链接后，看到一个类似讨论sql501n错误的帖子，大致提到在V9.7后，

DB2的游标规则做了改变，在游标OPEN阶段如果发生错误，是不会返回错误，在FETCH和CLOSE阶段会暴露错误，看到这里顿时感觉有

点思路，虽然目前V9.5.0.10而非V9.7，但是根据某些传闻，IBM的低版本软件的高FIX补丁相当于高版本，在回去分析这个存储过程，发现此

存储过程运行有以下：

1 如果失败的话，一般都是运行3分钟多失败，如果成功的话就不到三分钟，

2 如果失败的话，一般都是和另外一个存储过并行运行，如果成功的话都是在串行运行

3 此数据库的锁超时设置为3分钟





至此可以基本判定是锁超时导致的存储过程失败,于是在系统上部署了db2cos捕获锁超时，果然第二天捕获到了锁超时，并且与

存储过程的失败时间一致，之后的连续几天都捕获到了关于此存储过程的锁超时，在分析造成锁超时的表与上述的两个存储过程所涉

及的表一致，最后通过调整两个存储过程的执行关系，调整为串行执行后，在没有出现sql501n错误