我有四个连续运行的 SQL Agent 作业。每个作业都在执行一个存储过程，该过程查询最近的 ATM 交易，全部通过同一链接服务器进行。这在每个作业的循环中发生，过程执行之间有 5 秒的延迟（使用 WAITFOR DELAY）。
具体来说，四个作业中的一个使用一个存储过程，其他三个都使用另一个存储过程。每个作业执行都有自己的一组参数，这些参数与将触发响应的特定事务模式相关。它们都在查询同一个链接服务器。
大多数情况下，一切都运行正常。但偶尔（几乎*）任何作业都会因以下错误而失败：
TCP 提供程序：指定的网络名称不再可用。[SQLSTATE 42000]（错误 64）链接服务器“ATMDB”的 OLE DB 提供程序“SQLNCLI11”返回消息“通信链接失败”。[SQLSTATE 01000]（错误 7412）。
只有在作业更新为使用 WAITFOR 循环连续运行，而不是作为单独的 SQL Agent 作业执行每分钟运行一次后，这种情况才开始发生。进行此更改是为了避免过多的 SQL 作业日志记录，同时也是为了更接近实时地监控 ATM 交易。
它们失败的频率并不一致，但每天至少会发生几次。
*我上面说“几乎”，是因为其中一项作业从未失败过。这是最常获得“命中”的作业，当发生这种情况时，作业步骤就可以完成，因此我们在 SQL 作业日志中明确记录了这一点。（然后在 1 秒延迟后再次循环回到第一步。）
所有作业都配置为每分钟运行一次。因此，发生故障后，作业将在下一分钟重新启动，因此这不会造成太大影响。只是非常烦人！
我怀疑 SQL Native Client 及其实现连接池的方式是问题的根源。在测试时，我将两个程序之一中的链接服务器更新为与另一个不同。两个不同的主机名，但实际上仍然是同一台服务器（我只是使用 hosts 文件创建了一个新名称）。这导致一项作业不再失败，但其他三项作业中的两项仍会间歇性失败。在将另一个程序切换为再次使用相同的链接服务器后，现在所有作业都会再次偶尔失败。由于连接池特定于连接字符串，因此不同的服务器名称会导致使用不同的池。
使用 Windows 资源监视器，我可以看到通常有三个 TCP 连接打开到链接服务器。这些连接在几分钟内保持在同一端口上打开，所以我猜它正在使用某种连接池。当错误发生时，它恰好与其中一个连接关闭相吻合，不久之后就会打开一个新连接。
我目前的理论是：由于进程在使用链接服务器时不断循环，因此连接池中的某些东西会导致尝试使用因某种原因而关闭的连接的情况。也许偶尔“完成”的那个作业步骤会以某种方式刷新，并防止该特定进程发生错误。
我尝试将存储过程调用包装在 sp_executesql 中，作为一种解决方法来“强制”另一个进程或执行上下文，但这没有帮助。
两台服务器都是 Windows 2012，在 VMWare 中运行。
关于如何进一步排除故障有什么想法吗？
答案1
在用较新的硬件替换 VM 主机后，问题已自行解决。这表明这是一个网络/硬件级别的问题，而不是由于查询编程的具体方式或 SQL 的配置方式造成的问题。