Db2 IBM i（System i）V7R1升级导致ODBC连接上出现游标未打开错误

至少8年来，我们公司每天都在运行一个从未失败过的流程。客户端没有任何变化，但我们最近在Systemi上升级到V7R1。旧进程的第一次运行失败，并向客户端报告一条游标未打开消息，这也是作业日志中的全部内容。我有时会看到错误-501，SQLSTATE24501

我让IBM和DataDirect（ODBC驱动程序的提供者）都参与进来。IBM表示这是一个客户机问题，DataDirect通过日志挖掘发现，当从游标请求下一个记录块时，会发生此错误。他们看不到任何迹象表明系统i提醒客户光标已关闭

在故障排除过程中，我注意到ODBC驱动程序有一个选项用于WITH HOLD，默认情况下选中该选项。如果我取消选中它，这个特定的问题就消失了，但它引入了另一个问题（无限循环），它甚至更严重

没有一个共同的主题会导致这些错误，我所看到的唯一导致这些错误的原因是在循环通过一个相当大的结果集时进行了一些处理。它似乎与时间无关，也与特定的表或表类型无关。外部循环有时是具有许多数据类型的大型表，有时是只有CHAR（10）和CHAR（8）数据类型的小型表

我真的不希望在这里有答案，因为这是一个非常深奥的情况，但总有一些希望

IBM已经通过让我们应用PTFs将我们的数据库级别提高到36来解决了其他问题。我决不是一个系统专家，只是一个Java程序员，必须处理这个与Java无关的问题

---

谢谢

这就是我如何解决iseries上的DB问题的方法

开始记录iseries上的表，或者将与iseries的连接更改为commit=*NONE

对于日志记录，我建议使用两个日志，每个日志都有自己的接收器

一个日志用于更改相对较少的表格，如美国各州表格或每月更新少于10次的表格。这样您就可以确定何时更改数据以进行审核。让本日志的所有接收者永远在线

一天中有很多变化的表格的日记。当您负担不起这些日记账占用的空间时，请删除这些日记账的收件人

如果日志或提交*无无法修复它。您需要查看sysixadv表，长时间运行的查询可能会破坏ODBC连接

选择系统名称、TBMEMBER、索引类型、LASTADV、TIMESADV、ESTTIME、， 原因，“页面大小”，查询成本，查询列表，表格大小，NLSSNAME，
NLSSDBNAME、MTIUSED、MTICREATED、LASTMTIUSE、QRYMICRO、EVIVALS，
FIRSTADV、系统名称、MTISTATS、LASTMTISTA、来自sysixadv的部门
按ESTTIME desc订购

也可按时间ADV desc订购

---

修复这些查询可能会创建建议的索引。

您正在使用哪个ODBC驱动程序

如果您使用的是IBM i Access ODBC驱动程序，那么APAR可能会解决此问题。驱动程序并不总是处理来自服务器的返回代码，该返回代码指示结果集已关闭，在SQLCloseCursor函数期间，驱动程序将向服务器发送close命令，这将返回一个错误，因为服务器已经关闭了光标。注意，您不必在SP11就可以达到这个条件，这只是使它更容易达到，因为我在该修复包中启用了更多情况下的预取。要确定这是否是问题所在，一个简单的测试是禁用DSN的预取功能，或者在连接字符串上传递PREFETCH=0

---

如果您使用的是DB2 Connect驱动程序，很抱歉，我不能提供太多帮助。

这是为可能遇到类似问题的其他人提供的。原来是QRWTSRVR代码中的一个bug导致了这个问题。驱动程序在一个作业中打开了多个连接，并且在其中至少两个连接中使用了相同的游标名称。一旦其中一个游标关闭，QRWTSRVR将错误地尝试使用关闭的游标并返回错误。以下是工作组求职信中的描述：

针对APAR SE62670修复的问题说明：

---

PTF SI57756修复了该问题。我不知道该PTF是否会正式发布，但如果您因类似问题而发现此帖子，希望这将有助于您更正此帖子。

以前的版本是什么？这一点很重要，因为IBM在5.4和7.1之间对SQL进行了更改，以加强错误报告。为了帮助您排除故障，请直接在IBM i-get的绿色屏幕上尝试相同的SQL语句，并使用STRSQL运行失败的SQL语句。@BuckCalabro我们从V6R1到V7R1，问题是它不是一个失败的语句。该语句起作用，只是当ODBC驱动程序请求下一个结果块时，我只是报告光标已关闭。删除或重新排列客户机执行的代码会改变错误发生的点，有时会完全消除错误，但需要的是处理。@BuckCalabro说得很清楚，这与单个查询、单个表或单个数据类型无关，这是处理大型结果集时发生的间歇性奇怪故障。我对大没有明确的定义，但大到足以让ODBC驱动程序对结果块发出多个请求。错误发生在请求更多结果时。在不同平台上运行的目的是检查返回的行，以确保DB2现在不会返回以前从未返回过的警告。如果结果的第一个块没有任何不可靠的列（按抽签排序的幸运），那么第一个块将按预期返回。第23页。@BuckCalabro我已经想到了这一点，因为这类事情已经引起了

    A QRWTSRVR job with 2 cursors named C01 takes a MSGSQL0501
error when trying to fetch from the one that is open. The DB2
code is trying to use the cursor which is pseudo closed.