DB2 查询似乎挂起答案

【问题标题】：DB2 query seems to hangDB2 查询似乎挂起
【发布时间】：2018-10-29 10:02:32
【问题描述】：

我们的平台是：

DB2 ESE 10.5.8 运行于 IBM Power Linux Power 7 与红帽 RHEL 6.9（圣地亚哥）

问题是：有时某些请求会被“挂起”，因为它们似乎没有做任何事情，但它们仍然连接了几个小时（如果之前没有强制）并且不释放导致批处理作业的线程在这些请求被强制关闭之前，永远不会完成。

没有任何类型的锁（锁超时或死锁）。

db2top locks screen

这些图片显示了一个可能来自 dbvisualizer 的复杂查询，但有时该查询只是“从 sysdummy1 中选择当前模式；”但从未完成。

连接到数据库的应用程序是 Websphere Application Server (WAS) 8.5 和 dbvis (dbvisualizer)。问题发生在两者上，但更常见于 dbvis。

应用程序处于uow等待状态，也就是说，一旦之前的工作完成，它应该正在等待工作。另一方面，我没有解释这种连接如何导致批处理作业永远无法完成，因为这正是我不知道并且希望知道的。

换句话说：一个“UOW 等待”状态的应用程序当前什么都不做，只是在等待显示一个未完成的查询正在运行，这是一个悖论。

在这里您还可以看到 UOW 完成状态为已提交，据我所知，此应用程序句柄没有待提交的提交。

Application Snapshot
Application handle                         = 47954
Application status                         = UOW Waiting
Status change time                         = 10/29/2018 09:40:02.391805
Application code page                      = 1208
Application country/region code            = 0
Application name                           = dbvis
Connection request start timestamp         = 10/29/2018 09:38:33.022561
Connect request completion timestamp       = 10/29/2018 09:38:33.023248
Application idle time                      = 6 minutes 14 seconds
Previous UOW completion timestamp          = 10/29/2018 09:40:02.079211
Elapsed time of last completed uow (sec.ms)= 0.001282
UOW start timestamp                        = 10/29/2018 09:40:02.390511
UOW stop timestamp                         = 10/29/2018 09:40:02.391793
UOW completion status                      = Committed - Commit Statement
Workspace Information
Most recent operation                      = Static Commit
Most recent operation start timestamp      = 10/29/2018 09:40:02.391735
Most recent operation stop timestamp       = 10/29/2018 09:40:02.391793
Statement type                             = Static SQL Statement
Statement                                  = Static Commit
Statement start timestamp                  = 10/29/2018 09:40:02.391735
Statement stop timestamp                   = 10/29/2018 09:40:02.391793
Blocking cursor                            = NO

Statement type                             = Dynamic SQL Statement
Statement                                  = Fetch
Section number                             = 163
Cursor name                                = COL_DYNH
Statement start timestamp                  = 10/29/2018 09:39:57.544068
Statement stop timestamp                   = 10/29/2018 09:39:57.545429
Blocking cursor                            = YES

【问题讨论】：

这些连接上是否有未提交的事务，或者连接只是空闲？您尚未解释您所说的不持有锁的此类连接如何导致批处理作业永远无法完成。听起来你有不止一个问题。根据您的 Db2 许可证，考虑配置 WLM（或其他工具）以强制关闭空闲连接。
应用程序处于uow等待状态，即之前的工作完成后应该等待工作。我没有解释这种连接如何导致批处理作业永远无法完成，因为这正是我不知道并且希望知道的。换句话说：一个“UOW 等待”状态的应用程序当前什么都不做，只是在等待显示一个未完成的查询正在运行，这是一个悖论。通过处于 UOW 完成状态 = 已提交，我知道这个应用程序句柄没有提交待处理，尽管它永远不会完成，我不知道为什么。
“UOW 等待”表示 Db2-server 正在等待应用程序请求 Db2-server 做某事。通常这意味着应用程序（例如 dbvisualiser）处于空闲状态，“UOW 已提交”意味着没有未完成的事务。这些空闲连接不太可能与您提到的批处理作业“永远不会完成”的症状有关。来自 dbvis 的空闲连接不属于 WAS 连接池。您没有提供有关“永远不会完成”的批处理作业的任何事实，无论它们是 WAS 作业（或不是），还是它们正在做什么。信息不足。需要确定基本问题。
正如我之前评论的，连接到数据库的应用程序是 WAS 和 dbvis (dbvisualizer)。问题发生在两者上，但 dbvis 更常见，即 dbvis 比 WAS 更频繁地发生这种情况。我附上的例子是一个 dbvis 例子。上周我有一个 WAS 案例，直到我强制执行一个查询，该查询在 50 分钟无操作（无行读取，无行写入）后需要 2-3 秒才能完成，db2diag.log 和 db2inst1.nfy 什么也没显示。没有锁等待。该应用程序处于 UOW 等待状态，但未释放最后一个操作。我还能为您提供哪些信息？
如果批处理作业是 WAS 作业，并且如果它们未能完成，那么在它们被卡住时显示它们正在做什么的证据，使用 WAS 日志和 db2diag .log 来寻找证据。这是基本的问题确定。在应用程序、WAS、Db2 的诊断文件中查找症状并分析它们。

标签： java linux database db2 db2-luw

【解决方案1】：

dbvis 是否处于自动提交模式？

https://www.ibm.com/developerworks/community/blogs/IMSupport/entry/In_DB2LUW_why_a_session_with_status_UOW_Waiting_holding_locks_and_log_space?lang=en

【讨论】：

非常感谢，保罗！你解决了问题！！没错，就是这样。 dbvis 未处于自动提交模式。我已经能够通过设置自动提交关闭并将一行插入一个表来重现该问题。 db2top 立即将 select current schema from sysibm.sysdummy1 显示为持有 4 个锁的永不结束的查询（虽然它没有什么可看的，但那是另一回事了）。如果我将自动提交设置为 ON，则不会发生这种情况。 db2diag.log 和客户端的日志都没有显示任何相关内容。再次感谢您的帮助！