Sql server COM+；VB6应用程序：RM\u登记失败\u登记太多\u登记错误

我在从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\u登记失败\u登记过多\u登记错误

尝试登记资源管理器失败，因为已达到最大登记数量的限制。

据我所知，每个数据库的资源管理器应该保持一个正确的行为。
您知道有什么原因会触发这种意外行为，包括太多的资源管理器（每个管理器都有不同的guid）

---

需要注意的一点是，当我们在客户机和Db2连接机上从9.7 FP 9a切换到11.1.4 FP5 Db2驱动程序时，这种行为就开始了。

如果您已经将驱动程序（就地升级安装）从9.7升级到11.1，请尝试重新安装驱动程序（卸载、新安装、目录节点和数据库（如果需要）以及自定义配置）。

---

从9.7升级可能会在配置中留下一些不正确的地方，这可能会导致XA事务出现问题。

进行一些调查。查看SQL Server和Db2的诊断，并在工作站事件查看器中查找故障线索。在某个地方会有一些故障指示。您的问题与编程无关。您的问题是关于疑难解答的，因此您的问题不适用于编程网站。（疑难解答）您编辑的问题表示，在更新客户端工作站和Db2 connect服务器机器上的Db2驱动程序后，行为发生了变化。但您的问题显示了Microsoft驱动程序（ODBC的OLE DB提供程序）的使用情况。您是否仔细检查了Db2客户机诊断？您是否仔细检查了Db2 connect server诊断，并请求Db2服务器支持人员提供帮助？您是否向IBM支持人员开具了故障单？当然，我们检查了所有Db2跟踪，但没有发现任何问题。我们正在向IBM开具故障单，但我想问al在这里，以防有人遇到同样的问题。我想补充一点，我提出了一个这样的问题。是的，这是故障排除，但就像橡皮鸭调试一样；你慢慢地、逐步地向案例添加细节，关注问题，但也从有经验的人那里获得帮助和建议。问题文本建议s表明该问题是在负载增加的情况下触发的（向Db2发送更多查询）。您是否通过退回到前一个版本来消除Db2驱动程序版本，只是为了证明增加的负载是否不会导致旧驱动程序出现症状？行为表明，当对Db2的查询可能没有按预期的速度完成时，msdtc会打开多个到Db2的连接。回滚到旧版本在我们的检查表中，但这并不容易；我们尝试回滚几周前遇到的另一个问题，但卸载失败。查询读取日志的速度非常快（以毫秒为单位）。我从日志中看到，在问题出现之前，登记的资源管理器与执行的查询之间没有1:1的相关性。

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'"