使用 DB2 Connect JDBC t4 驱动程序在 z/OS 下达到某些限制
我们有一个应用程序连接到 z/OS 下的 DB2，一段时间后，大型机端似乎遇到了一些资源限制。由于我们使用 BIRT，因此我们对 JDBC 代码的唯一控制似乎是 URL 本身中的节。我们没有对连接或语句的直接 Java 控制（当然 SQL 本身除外），尽管可以通过在报表设计中使用 Javascript 来实现。因此，我们可以通过以下方式打开调试：
jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;
最终，使用 JDBC 的应用程序将停止，并且不会将更多数据写入日志文件。在大型机上执行 TSO NETSTAT 显示大约 50 个处于 ESTABLISHED 状态的会话。
现在我们知道这是大型机端的问题，因为当它发生时，到该实例的 JDBC 连接将无法工作（来自任何客户端）。此时，我们必须重新启动数据库才能继续。
我在谷歌上搜索了很多东西，其中一些似乎表明您可能需要在关闭会话之前提交查询。会话可能保持打开状态是因为 BIRT 关闭代码中存在问题（至少就 DB2 所期望的而言）。
以前有人经历过类似的事情吗？你是如何解决这个问题的（如果有的话）？有没有办法通过在报表设计中仅使用 JDBC URL 节或 Javascript 代码来解决这个问题？
FWIW，我们使用 DB2 9.1 和 BIRT 2.2.1。
We have an application connecting to DB2 under z/OS and, after a while, there seems to be some resource limit being hit on the mainframe side. Since we're using BIRT, it seems the only control we have over the JDBC code is with stanzas in the URL itself. we don't have direct Java control over the connection or statements (except for the SQL itself of course) although it may be possible by using Javascript within the report design. So we can turn on debugging with something like:
jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;
Eventually the application using JDBC will simply stop and no more data will be written to the log file. Doing a TSO NETSTAT on the mainframe shows about 50 sessions in ESTABLISHED state.
Now we know this is a problem on the mainframe side since, when it happens, no JDBC connection to that instance will work (from any client). At that point, we have to restart the database to continue.
I've googled quite a lot of stuff, some of which seems to indicate that you may need to commit queries before you close a session. It may be that the sessions may be being held open because there's something wrong in the BIRT close code (at least in terms of what DB2 expects).
Has anyone experienced anything like this before? How did you fix it (if at all)? Is there a way to solve it by using just the JDBC URL stanzas or Javascript code within the report design?
FWIW, we're using DB2 9.1 and BIRT 2.2.1.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这实际上在另一个论坛中得到了解决，我将解决方案复制到这里供后代使用。
事实证明，DB2 参数汇编/链接作业的
DSN6FAC部分中有一个名为IDTHTOIN的参数（通常是 db2prefix.SDSNSAMP( DSNTIJUZ）（尽管您的设置可能不同），在我们的例子中设置为零。此参数是 DDF 线程的 IDLE TIME OUT，零表示“无超时”。将其设置为 180 解决了我们的问题。如果持有锁的线程在这三分钟内没有任何活动，则会被关闭。将其设置为小于 120 是没有用的，因为无论如何，线程仅每两分钟检查一次（至少在 DB2 v9 中）。
您还应该设置 CMTSTAT=INACTIVE 来保护行为良好的线程（那些已释放所有资源锁但仍保持线程打开状态的线程）。
请记住，这对于我们的特定问题来说是可以的，因为线程用于报告。他们的行为是打开一个会话，获取用于报告的数据，然后不再需要该会话。如果您有长时间运行的会话，则需要小心（尽管任何持有锁超过三分钟的会话无论如何都是可疑的）。
您应该编辑
DSNTIJUZ成员，运行作业，然后回收 DB2 实例或执行SET SYSPARM。感谢 IBM 澳大利亚（西珀斯实验室）的热心人士为我解决了这个问题。
This was actually solved in another forum, I'm copying the solution here for posterity.
It turns out there's a parameter called
IDTHTOINin theDSN6FACsection of the DB2 parameters assembly/link job (generally db2prefix.SDSNSAMP(DSNTIJUZ)though your setup may be different) which was set to zero in our case. This parameter is theIDLE TIME OUTforDDFthreads and zero means "no timeout".Setting this to 180 solved our problem. The threads that were holding locks were shut down if they hadn't had any activity in those three minutes. Setting it to less than 120 is not useful since the threads are only checked every two minutes anyway (in DB2 v9 at least).
You should also set
CMTSTAT=INACTIVEto protect well-behaved threads (those that have released all their resource locks but are still holding the thread open).Keep in mind this was okay for our particular problem since the threads were for reports. Their behavior was such that the opened a session, got the data for reporting, then didn't need the session any more. If you have long-running sessions, you need to be careful (although any session that holds locks for more than three minutes is suspect anyway).
You should edit the
DSNTIJUZmember, run the job, then either recycle the DB2 instance or executeSET SYSPARM.Thanks to the helpful bods at IBM Australia (West Perth Lab) for nutting this out for me.