![如何开始诊断间歇性 SQL Server 连接错误?](https://linux22.com/image/695914/%E5%A6%82%E4%BD%95%E5%BC%80%E5%A7%8B%E8%AF%8A%E6%96%AD%E9%97%B4%E6%AD%87%E6%80%A7%20SQL%20Server%20%E8%BF%9E%E6%8E%A5%E9%94%99%E8%AF%AF%EF%BC%9F.png)
我们的多个 Web 应用程序出现间歇性错误,均提示同一件事:
System.Data.SqlClient.SqlException:与 SQL Server 建立连接时发生与网络相关或特定于实例的错误。未找到或无法访问服务器。验证实例名称是否正确以及 SQL Server 是否配置为允许远程连接。(提供程序:命名管道提供程序,错误:40 - 无法打开与 SQL Server 的连接)---> System.ComponentModel.Win32Exception:未找到网络路径
我们无法在命令上重现该问题;99% 的时间一切都正常。我们每天会看到这些错误 2 到 3 次。发生的时间不一致。我们在 AWS 中运行两个独立的服务器:一个 SQL Server Standard 2016 服务器和一个运行 .NET Web 应用程序的独立服务器。Web 应用程序通过 ADO.NET 连接。
我们如何开始诊断这些错误?
有哪些日志可以打开?我们应该先排除什么?
答案1
实际上,我们在使用 pymssql 驱动程序的 Python 应用程序中也遇到过类似的情况。我们的具体消息是“意外的 EOF”。我们从来没有弄清楚。我们只是在客户端实现了重试...
我们尝试了很多方法。作为常规监控,我们监控活动 TCP 连接的数量。也许它们超过了 SQL Server 的最大值?但一切都很好。
最后,我们运行了tcpdump
捕获所有流量的程序,这样我们就可以在 Wireshark 中查看它。将其设置为显示 UTC 时间,这样您就可以匹配日志条目。也许还可以记录该特定连接的返回 TCP 端口或其他可识别信息。
我们发现服务器有时会FIN
在 TDS 登录前消息后立即发送一个 (finish) 数据包。找不到很好的理由。远远没有达到最大连接数。
我想对于你的情况我会:
- 使用 tcpdump 技巧
- 编写每分钟连接一次的测试脚本或小应用程序,看看是否可以以这种方式重现它。
- 如果您能通过这种方式重现此问题,请尝试通过简单的 TCP 连接该端口,看看是否也会失败。由于您的错误是“未找到网络路径”,因此可能确实如此。
答案2
如果您的应用程序有时可以连接到 SQL Server,有时却不能,那么排除故障可能非常困难。如果 SQL Server 甚至没有收到呼叫,它就无法记录任何错误。
为了找到根本原因,我提出了以下问题:
当它发生时,它会发生在所有应用程序上吗?例如,您是否有针对 SQL Server 的监控工具,并且即使在发生问题时它们是否能够持续连接到 SQL Server?
所有应用服务器都会发生这种情况吗?如果您有多个应用程序或 Web 服务器,它们都会受到影响吗?(如果您只有一个,那么现在是设置另一个进行故障排除并平衡它们之间负载的绝佳时机。)
应用程序中的所有查询都会受到影响吗,还是只有部分查询受到影响?有时我看到长时间运行的查询继续进行,但只有新连接受到影响。
SQL Server 或应用程序服务器中是否记录了任何错误?有一次,我们发现所有应用服务器经常同时失去网络连接。原来是交换机出了问题。
超时的日子/时间是否有规律?开始写下来或记录它们发生的时间。例如,在一个案例中,我们发现日期/时间与安全团队定期安排的端口扫描完全相关。
在超时期间,应用服务器是否能够 ping SQL Server? 当所有其他方法都失败后,我们在应用服务器上安装了免费的网络监控工具,每 10 秒 ping 一次 SQL Server。果然,下次应用程序查询超时时,我们能够证明 ping 不起作用 - 从而排除了 SQL 问题。
问这些问题,有时您甚至根本不需要排除 SQL Server 故障 - 答案说明了整个情况。
答案3
使用 TCP 而不是命名管道。
使用以下说明作为禁用命名管道的指南:https://www.blackbaud.com/files/support/infinityinstaller/content/installermaster/tkenablenamedpipesandtcpipconnections.htm