COM+ VB6 应用程序: RM_ENLIST_FAILED_TOO_MANY_ENLISTS 错误

Question

我在从VB6应用程序（Com+）启动的事务中遇到了奇怪的行为， 这个传统的应用程序在同一个事务内调用DB2和SQLServer中的多个查询。
返回的错误信息为：

[Microsoft][ODBC Driver Manager] Failed to enlist on calling object's transaction query=SELECT COUNT (*) as FOO FROM BAR
          FOR FETCH ONLY WITH UR SorgenteErr: Microsoft OLE DB Provider for ODBC Drivers
9:42:42 AM [2032]: Error: -2147467259

通常情况下，msdtc日志会显示类似以下的2个资源管理器的登记信息：

pid=2440       ;tid=4636       ;time=10/08/2020-10:48:11.404   ;seq=535        ;eventid=RM_ENLISTED_IN_TRANSACTION               ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7     ;"TM Identifier='(null)                                            '" ;"resource manager #1002 enlisted as transaction enlistment #1. RM guid = '62f2ad11-5eab-45f9-89d6-53d7488cfb6e'"
pid=2440       ;tid=4636       ;time=10/08/2020-10:48:11.545   ;seq=536        ;eventid=RM_ENLISTED_IN_TRANSACTION               ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7     ;"TM Identifier='(null)                                            '" ;"resource manager #1003 enlisted as transaction enlistment #2. RM guid = 'bd440a1c-7334-4170-b1d5-a5c9e25eb1a0'"

在某种情况下，由于一些应用程序逻辑，查询数量增加时，我们会遇到奇怪的行为；通常应用程序按预期工作，但有时资源管理器会奇怪地从2增加到32，触发RM_ENLIST_FAILED_TOO_MANY_ENLISTS错误。 尝试注册资源管理器失败，因为已达到最大注册数限制。

pid=2440       ;tid=4636       ;time=10/23/2020-10:48:17.810   ;seq=566        ;eventid=RM_ENLISTED_IN_TRANSACTION               ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7     ;"TM Identifier='(null)                                            '" ;"resource manager #1033 enlisted as transaction enlistment #32. RM guid = '5596fb4e-6c48-441c-af48-2d17adfb4ea0'"
pid=2440       ;tid=4636       ;time=10/23/2020-10:48:18.092   ;seq=567        ;eventid=RM_ENLIST_FAILED_TOO_MANY_ENLISTS        ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7     ;"TM Identifier='(null)                                            '" ;"attempt to enlist the resource manager failed because the limit on number of maximum enlistments has been reached. RM guid = 'e260c743-46b4-4f96-a343-1553bc7974eb'"

据我所知，资源管理器在正确的行为中应该每个数据库保留一个。
您知道是否有任何原因会触发这种意外行为，即列举过多的资源管理器（每个都具有不同的guid）？

需要注意的一件重要的事情是，当我们从9.7 FP 9a切换到客户端机器和DB2连接机器上的11.1.4 FP5 Db2驱动程序时，这种行为开始出现。

- systempuntoout

---

进行一些调查。在SQL-Server和Db2的诊断中查找，并在工作站事件查看器中寻找故障线索。总会有一些故障指示。你的问题不是关于编程的。你的问题是关于故障排除的，因此你的问题不适合在编程网站上提问。 - mao

（故障排除）您编辑的问题表明，在客户端工作站和 Db2 连接服务器机器上更新了 Db2 驱动程序后，行为发生了变化。但是，您的问题显示使用了 Microsoft 驱动程序（ODBC 的 OLE DB 提供程序）。您是否仔细检查了 Db2 客户端诊断？您是否仔细检查了 Db2 连接服务器诊断，并向 Db2 服务器支持人员请求帮助？您是否向 IBM 支持开了一个故障工单？ - mao

当然，我们检查了所有的db2跟踪，但是我们没有看到任何异常。我们正在向IBM开放一个工单，但我也想在这里问一下，以防有人遇到了同样的问题。我想补充一下，七年前我曾经提出过这样的问题，链接。是的，这是故障排除，但就像橡皮鸭调试一样；你会逐步添加案例细节，专注于问题，同时从经验丰富的人那里获得帮助和建议。 - systempuntoout

问题描述表明该问题是在增加负载（发送更多查询到Db2）下触发的。您是否通过回退到以前的版本来消除了Db2驱动程序版本，仅仅是为了证明旧驱动程序不会因为增加的负载而导致症状？行为表明当对Db2的查询可能没有像它预期的那样快速完成时，msdtc会打开多个与Db2的连接。 - mao

回滚到旧版本在我们的清单中，但并不容易；我们尝试回滚另一个问题几周前，但卸载失败了。查询非常快（在毫秒级别），读取日志。从日志中我看到的是，资源管理器注册和查询执行之间没有一对一的关联，直到问题出现。 - systempuntoout

Answer 1

如果您已将驱动程序（原地升级安装）从9.7升级到11.1，请尝试重新安装驱动程序（卸载、新安装、目录节点和必要时的数据库以及自定义配置）。从9.7升级可能会在配置中留下一些不正确的内容，这可能会导致XA事务出现问题。

- MountainSinger