Azure 数据工厂 - 自托管集成运行时 - ODBC 驱动程序之谜

Question

我们将Self-Hosted Integration Runtime 用于Azure Data Factory。

在那台机器上安装了版本 6 的 Exasol ODBC 驱动程序。我们想升级驱动程序，删除了一个旧驱动程序并安装了版本 7 的新驱动程序。

奇怪的是，现在在 Exasol 日志中，我们可以看到数据工厂有时通过驱动程序版本 7 连接，有时通过驱动程序版本 6 连接。

我做了一个实验，从机器上完全删除了 Exasol ODBC 驱动程序。之后，数据工厂仍然能够使用我刚刚删除的驱动程序连接到 Exasol。

看起来驱动程序的 DLL 缓存在某处。会是什么？

更新 1

当 Data Fatory 使用版本 6 的 ODBC 驱动程序连接到 Exasol 时，我在 Process Monitor 中捕获了以下操作：

这些C:\Config.Msi\3739be5*.rbfASolution-6.1\ODBC\ DLL 可能来自哪里？机器上没有C:\Config.Msi\目录。

更新 2

我注意到，当我在机器上通过Microsoft Integration Runtime Configuration Manager 或Data Factory Linked Service 测试连接时，总是使用版本 7 的 ODBC 驱动程序进行连接。

但是当我通过Data Factory Dataset 测试连接时，在某些情况下，连接是使用版本 6 的 ODBC 驱动程序完成的。

Answer 1

您可以检查注册表，但风险自负。一个替代方案可能是SysIternals tools、Process Monitor 或Process Explorer，这可能会帮助您深入了解这一点。如果允许，将它们安装在 SHIR VM 上。特别是 Process Explorer 有点像 SQL Profiler（如果您曾经使用过它），因此能够告诉您外部进程正在使用哪些注册表项。它将为您提供大量信息，因此您必须明智地使用时间戳和过滤。建议的步骤：

• 使用进程监视器启动跟踪
• 使用 Exasol 驱动程序启动管道
• 等到它完成（或者至少您知道它已经开始）
• 停止进程监视器跟踪 花时间检查数百万 它已捕获、尝试过滤或搜索您的记录 过程

另一种方法是构建一个干净的 SHIR 并仅安装新的驱动程序。然后把它换成旧的。如果这对您来说是个问题，您可能需要将新的 SHIR 添加到防火墙中。

老实说，我会建议将这两种方法并行处理以解决生产问题。 Procmon / Process Explorer 可能会耗费大量人力和时间，但应该可以帮助您找到问题的根源。从长远来看，建造更清洁的 SHIR 可能是更安全的选择，但需要新的基础设施。

Answer 2

这听起来可能很傻，但是重启 SHIR 正在工作的服务器解决了这个问题。 我们注意到，这台服务器运行了 30 多天，并决定重新启动它。也许重新启动 Integration Runtime 服务本身也会有所帮助，但我们没有这样做。 感谢大家的帮助。