DB2 ODBC 连接挂起

Question

我已在 Windows 10 上安装了 DB2 11.5.7（和 11.5.8）。 我已经创建了示例数据库（使用 db2sampl）。
当我尝试通过 ODBC 连接到该数据库时，它挂在连接阶段（我必须终止进程）。
从我的 x86 应用程序 (C++) 或 ODBC 数据源管理器（32 位）建立连接并不重要。

• 在上面的屏幕截图中，我刚刚按下“连接”按钮。
• ODBC 数据源管理器变得无响应并充分利用 1-2 个 CPU 核心
• 这种情况并非每次都会发生，但 98% 的尝试都会挂起。有时我很幸运，但重新启动 ODBC 数据源管理器（32 位）就足够了，连接再次挂起。

如果我启动 ODBC 数据源管理器（64 位）- 连接总是成功。

我的机器的一些附加信息：

• 它是迷你电脑 - Beelink SER6 Pro 7735HS
• AMD 锐龙 7 7735HS

在我测试的所有其他机器上没有任何类似问题。

我尝试过的：

• 输入正确和错误的用户密码 - 在两种情况下都会挂起
• 在 Windows 11 上执行 - 连接挂起
• 在 Windows 10 上执行 - 连接挂起
• 在带有来宾 Windows 10 的虚拟机 (VMWare) 下执行它 - 连接挂起
• 连接到远程 DB2 服务器 - 连接也挂起
• 从另一台机器连接到这台机器 - 另一台机器连接成功
• 尝试过 DB2 版本：11.5.7 和 11.5.8 - 两个连接都挂起
• ODBC 数据源管理器（64 位）- 连接成功

我希望从 ODBC 32 位成功连接。

Answer 1

终于找到解决办法了:)

根据我的 C++ 应用程序调用堆栈并处理由 ProcMon 捕获的事件，我几乎确信挂起发生在 icclib 内部（通过堆栈），并且它是 GSKIT 的一部分。

所以我决定在谷歌中搜索与 GSK8 相关的一些挂起问题，瞧我发现了这个 IBM 报告的问题：

IJ44774：AMD EPYC 系列 25 处理器的 GSKIT 问题

错误描述

Commands like mmcrcluster or mmaddnode may hang in GSKIT
layer on AMD EPYC family 25 processors.  A particular model
from family 25 that is known to hang in GSKIT layer is
AMD EPYC 7343.

本地修复

Add "ICC_SHIFT=3" line in
/usr/lpp/mmfs/lib/gsk8/Cicc/icclib/ICCSIG.txt
file on problem nodes.

...

症状：

Admin commands hangs

受影响的平台：

Linux OS environments

受影响的功能区：

Admin Commands, gskit

• 它描述了 Linux 的修复，但是！就我而言，它是 Windows！

Windows 上 ICCSIG.txt 的路径：

C:\Program Files (x86)\ibm\gsk8\lib\C\icc\icclib\ICCSIG.txt

• 我刚刚在该文件末尾添加了

  ICC_SHIFT=3

  ，就是这样！

Answer 2

感谢您发布此内容。在数据中心崩溃后，客户被迫将我们的数据仓库平台紧急迁移到 Azure，之后我遇到了类似的问题。

我们的场景略有不同，但最终结果是相同的。我们能够稍微及时地进行连接，但是对结果集进行任何类型的查询或目录查找都会迷失方向。小型单行查询将正常返回数据。

我的客户正在使用 IBM DB2 Client 11.5 x32/x64 运行 Azure Windows 2022 Data Center。 （我也尝试过10.5 IBM客户端，结果相同）。

我发现，随着返回数据包大小的增加，响应时间呈指数增长。

DB2 客户端有一个名为 DB2Ping 的工具，它对于可视化这一点非常有用。 （从提升的 DOS 提示符运行，运行 DB2CMD 以打开 DB2 命令行处理器。）我创建了一个批处理文件来运行一系列增加返回数据包大小的命令，您可以从命令行运行它们，只需确保执行以下操作首先连接，最后断开连接（将 中的值替换为您的值）

这是确定您是否也遇到数据包丢失/碎片问题的简单方法：

当返回数据包大小小于1400字节时，结果符合预期。当数据包超过 1455 个时，响应时间变得不稳定且缓慢。

我在 Azure 服务器上的 DB2 客户端安装文件夹中找到了 ICCSIG.txt 文件。从内容来看，其中有 6. 3 个文件似乎是“丢失文件”的占位符。 3 看起来是合法的，带有#Don't change everything above here”评论。为了确定起见，我编辑了所有 6 个文件。

瞧...我们又恢复正常了，DB2 的查询时间符合预期。希望能够解释“为什么”，但无论这个设置做什么，都为我解决了问题。