1

我们有一个应用程序在 z/OS 下连接到 DB2，过了一段时间，似乎在大型机端遇到了一些资源限制。由于我们使用的是 BIRT，我们对 JDBC 代码的唯一控制似乎是 URL 本身中的节。我们没有直接的 Java 控制连接或语句（当然除了 SQL 本身），尽管在报表设计中使用 Javascript 可能是可能的。所以我们可以通过以下方式打开调试：

jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;

最终，使用 JDBC 的应用程序将简单地停止，不再向日志文件写入数据。TSO NETSTAT在大型机上执行 a会显示大约 50 个会话处于ESTABLISHED状态。

现在我们知道这是大型机方面的问题，因为当它发生时，到该实例的 JDBC 连接将不起作用（来自任何客户端）。此时，我们必须重新启动数据库才能继续。

我搜索了很多东西，其中一些似乎表明您可能需要在关闭会话之前提交查询。可能因为 BIRT 关闭代码中有问题（至少在 DB2 所期望的方面），会话保持打开状态。

有没有人经历过这样的事情？你是如何修复它的（如果有的话）？有没有办法通过在报告设计中仅使用 JDBC URL 节或 Javascript 代码来解决它？

FWIW，我们使用的是 DB2 9.1 和 BIRT 2.2.1。

4

1 回答 1

1

这实际上是在另一个论坛中解决的，我在这里复制解决方案以供后代使用。

事实证明，在 DB2 参数组装/链接作业部分（通常是db2prefix，尽管您的设置可能不同）中调用IDTHTOIN了一个参数，在我们的例子中该参数设置为零。这个参数是线程的，零表示“没有超时”。DSN6FAC.SDSNSAMP(DSNTIJUZ)IDLE TIME OUTDDF

将此设置为 180 解决了我们的问题。如果在这三分钟内没有任何活动，则持有锁的线程将被关闭。将其设置为小于 120 是没有用的，因为无论如何只每两分钟检查一次线程（至少在 DB2 v9 中）。

您还应该设置CMTSTAT=INACTIVE保护行为良好的线程（那些已释放所有资源锁但仍保持线程打开的线程）。

请记住，这对于我们的特定问题是可以的，因为线程是用于报告的。他们的行为是打开一个会话，获取报告数据，然后不再需要会话。如果您有长时间运行的会话，则需要小心（尽管任何持有锁超过三分钟的会话无论如何都是可疑的）。

您应该编辑DSNTIJUZ成员，运行作业，然后回收 DB2 实例或执行SET SYSPARM.

感谢 IBM 澳大利亚（西珀斯实验室）的乐于助人的团队为我解决了这个问题。

于 2009-09-30T01:36:20.917 回答