我们正在为 Azure Data Factory 使用自托管集成运行时。
在该机器上安装了版本 6 的Exasol ODBC驱动程序。我们想升级驱动程序，删除了旧的驱动程序，并安装了版本 7 的新驱动程序。
奇怪的是，现在在Exasol日志中，我们可以看到数据工厂有时通过驱动程序版本 7 进行连接，有时还通过驱动程序版本 6 进行连接。
我做了一个实验，并完全从机器上删除了Exasol ODBC驱动器。之后，数据工厂仍然能够使用我刚刚删除的驱动程序连接到Exasol。
看起来驾驶员的DLL被缓存在某个地方。可以是什么？
更新1
我在过程中捕获了以下操作当与版本 6 的odbc驱动程序连接到exasol时，：
这些 c：\ config.msi \ 3739be5*.rbfasolution-6.1 \ odbc \ dlls可能来自？机器上没有 c：\ config.msi \ 目录。
更新2
我注意到，当我通过 Microsoft Integration Runtime Configuration Manager 在计算机上或数据>数据出厂链接服务中测试连接时，连接始终是使用版本 7 的ODBC驱动程序执行。
但是，当我通过数据出厂数据集测试连接，在某些情况下，连接是使用版本 6 的ODBC驱动程序完成的。
We are using a Self-Hosted Integration Runtime for Azure Data Factory.
On that machine there was installed an Exasol ODBC driver of version 6. We wanted to upgrade the driver, deleted an old one and installed a new driver of version 7.
Weird thing is that now in Exasol logs we can see that Data Factory is sometimes connecting via driver version 7, and sometimes via driver version 6.
I made an experiment and deleted Exasol ODBC driver from the machine completely. After that Data Factory still was able to connect to Exasol using the driver I just deleted.
Looks like drivers' DLLs are cached somewhere. What can it be?
Update 1
I captured following actions in Process Monitor when Data Fatory connected to Exasol with ODBC driver of version 6:
Where these C:\Config.Msi\3739be5*.rbfASolution-6.1\ODBC\ DLLs may come from? There is no C:\Config.Msi\ directory on the machine.
Update 2
I noticed that when I test connection via Microsoft Integration Runtime Configuration Manager on the machine or in Data Factory Linked Service, then connection is always performed with ODBC driver of version 7.
But when I test connection via Data Factory Dataset, then in some cases connection is done with ODBC driver of version 6.
发布评论
评论（2）
您可以检查注册表，但会自行清洁。另一种选择可能是 sysiternals工具， Process Monitor 或 Process Explorer 这可能有助于您进入底部。如果允许您将它们安装在Shir VM上。尤其是Process Explorer有点像SQL Profiler（如果您曾经使用过），因此可以告诉您使用哪些注册表键外部流程正在使用。它将为您提供很多信息，因此您必须明智地使用时间戳和过滤。提出的步骤：
它捕获的记录，试图过滤或搜索您的
处理
替代方法是建造一个干净的雪尔，仅安装新驱动程序。然后将其换成旧的。如果这是您的问题，则可能需要将新的Shir添加到防火墙中。
老实说，我会提出这两个并行解决生产问题的方法。 ProcMon / Process Explorer可能会很昂贵，但应该帮助您进入问题的底部。从长远来看，建造更清洁的雪尔可能是一个更安全的选择，但需要新的基础设施。
You could check the registry but clean at your own risk. An alternative might be the SysIternals tools, Process Monitor or Process Explorer which might help you get to the bottom of this. Install them on the SHIR VM if you are allowed to. Process Explorer in particular is a bit like SQL Profiler (if you've ever used that) so will be able to tell you which registry keys external processes are using. It will give you a lot a lot of information so you will have to make judicious use of timestamp and filtering. The proposed steps:
of records it has captured, trying to filter down, or search for your
process
An alternative would be to build a clean SHIR and install only the new driver. Then swap it in for the old one. You may have to get the new SHIR added to the firewall if this is an issue for you.
Honestly I would propose both of these approached in parallel for a production problem. Procmon / Process Explorer can be quite labour and time expensive but should help you get to the bottom of the issue. Building a cleaner SHIR is probably a safer option in the long-term, but requires new infrastructure.
听起来可能很愚蠢，但是重新启动Shir正在工作的服务器解决了问题。
我们注意到该服务器运行了30天以上，并决定重新启动它。也许重新启动集成运行时服务本身也会有所帮助，但我们没有这样做。
感谢大家的帮助。
It may sound silly, but rebooting the server where SHIR is working solved the problem.
We noticed, that this server was running for more than 30 days, and decided to reboot it. Maybe restarting Integration Runtime service itself would also help, but we didn't do it.
Thanks to everyone for you help.