排查连接到 SQL Server 时出现间歇性或定期问题
网络稳定性对于各种服务和应用程序的顺利运行至关重要。 但是，有时网络问题会中断这种稳定性。 本文可帮助你了解和解决间歇性或定期网络问题及其典型错误消息。 这些问题可能会令人沮丧，但可以通过更好地了解和适当的故障排除技术更有效地解决这些问题。
最常见的错误消息
间歇性问题不规则发生，而定期问题往往以可预测的间隔发生。 确定问题类型是故障排除的第一步。 出现间歇性或定期网络问题时，可能会遇到以下错误消息：
- 通信链接失败：此错误表示网络组件之间的通信中断。
- 连接超时已过期：与服务器的连接超时超时，建议服务器延迟或不可用。
- 常规网络错误：常规网络错误消息通常表示网络未指定的问题。
- 传输级别错误：此错误发生在传输层，这表示数据传输存在问题。
- 指定的网络名称不再可用：此消息表示无法访问指定的网络资源。
- 信号灯超时：此错误指向与网络中信号灯的使用相关的超时条件。
- 等待操作超时：等待操作已超过其允许的时间，通常是由于网络延迟。
- 从网络读取输入流时发生致命错误：从网络读取数据时，此消息显示严重错误。
- TDS 流中的协议错误：表格数据流（TDS）是 SQL Server 使用的协议。 此错误表示协议存在问题。
- 找不到或无法访问服务器：此错误消息表明您尝试访问的服务器不可用或找不到。
- SQL Server 不存在或访问被拒绝：此错误可以指示尝试访问 SQL Server 时缺少 SQL Server 或身份验证错误。
原因
最常见的问题与由于防病毒、网络优化、较旧的网络驱动程序、路由器或交换机错误以及应用程序中的非共用连接而导致的数据包丢弃有关。
某些原因（如防病毒）可能很难证明，但仍很常见。 你可能必须卸载并重新启动计算机来证明它，而无需明确的证据。 为 SQL Server 创建异常也可能起作用。 但是关闭防病毒通常不起作用，因为即使网络筛选器驱动程序不受监视，网络筛选器驱动程序仍在加载。
疑难解答流程
注意
此过程专为 SQL Server 客户端和服务器连接而设计。 不会解决其他通信，例如 SQL Server 镜像、Always-On 和 Service Broker 同步流量（通过端口 5022）。
一般情况下，故障排除应该由数据驱动，这可能会让位给更集中的上下文中的经验测试。 如果问题非常间歇性，网络跟踪将难以捕获， 则经验方法 可能首先应用。
在每台计算机上使用 SQLCHECK 收集报表
在每台计算机上运行 SQLCHECK 以生成报表。 确定连接失败的原因很有用。
在客户端和服务器上收集网络跟踪
在 Windows 计算机上，使用 SQLTRACE 收集网络跟踪。
按照以下步骤准备并跟踪。 步骤 2 和步骤 3 只需完成一次。
下载最新版本的 SQLTRACE 并将其解压缩到文件夹，例如 C：\MSDATA。
打开 SQLTrace.ini 文件并关闭以下设置：
BIDTrace=no、AuthTrace=no和EventViewer=no保存文件。
以管理员身份打开 PowerShell，并将目录更改为包含 SQLTrace.ps1 的文件夹。
CD C:\MSDATA启动跟踪集合。
.\SQLTrace.ps1 -start重现问题或等待错误发生。
停止跟踪。
.\SQLTrace.ps1 -stop
输出文件夹在当前目录中生成，你可以使用它进行进一步分析。
在非 Windows 计算机上，使用 TCPDUMP 或 WireShark 收集数据包捕获。
运行 SQL Server 网络分析器
SQL 网络分析器 UI （SQLNAUI） 提供了一个图形界面，用于选择用于分析和设置选项的跟踪文件。 从 SQL 网络分析器（SQLNA）下载它。
单独处理客户端和服务器跟踪。 如果已链接跟踪，请同时处理它们。 这些文件的总大小不应超过计算机的内存的 80%。 确保有足够的内存来处理所有相关跟踪文件。
此工具将生成可疑问题的报表和 CSV 文件，你可以在 Excel 中浏览该文件进行备用研究。
尝试在客户端跟踪和服务器跟踪中找到匹配的对话。 通常，IP 地址和端口号匹配。 但是，如果连接通过任何类型的网络地址转换或端口映射，则可能更困难，并且可能需要使用 IPV4 数据包 ID 进行排队，并比较有效负载。
在网络跟踪分析中查找的模式
检查会话在 NETMON 或 WireShark 中的结束方式。 检查客户端和服务器是否同意相同的内容，或者它们是否讲述了不同的故事。
SSL 握手期间关闭的连接
在 ServerHello 数据包中，如果使用的密码套件是 Diffie-Hellman 套件，并且流量介于 Windows 2012 或更早版本和 Windows 2016 或更高版本之间，则此算法从 Windows 2016 安全修补程序开始更改。 应禁用此组密码套件。 有关详细信息，请参阅在 Windows 中连接 SQL 服务器时应用程序强制关闭 TLS 连接错误。
如果在 ClientHello 之后关闭了连接，请检查客户端和服务器之间是否存在 TLS 1.0 或 TLS 1.2 不匹配的情况。 如果它们相同，请检查两台计算机上已启用的密码套件和已启用哈希。
有关详细信息，请参阅 高级安全套接字层数据捕获。
删除的数据包数
查看匹配对话的结束。 如果有多个重新传输的数据包（或 10 个保持连接数据包、1 秒分开），后跟 ACK+RESET，或者一个报告及时响应，另一个报告它延迟并关闭或重置会话，这表示网络设备和数据包被丢弃或延迟的问题。
还可能会看到指示服务器重置会话的客户端报告，以及指示客户端重置会话的服务器报表。 这是因为开关或路由器关闭了中间的连接，有时可以配置为这样做，如果他们检测到连接已空闲一段时间-通常忽略 Keep-Alive 数据包。
有关已删除的连接的详细信息，请参阅：
服务器跟踪和客户端跟踪都同意问题在客户端上
如果两个跟踪在客户端上显示延迟或无响应，或者客户端在确认服务器响应后发出 ACK+RESET，或者，在登录序列中提前关闭连接，则需要在客户端上获取 BID 跟踪和 NETSH 跟踪，以在 TCP/IP 堆栈中查看 TCP/IP 堆栈以及驱动程序的想法。 如果防病毒或其他网络筛选器驱动程序延迟接收数据包或发送回复，则这种情况很常见。 连接超时也可能是由于 DNS 响应缓慢或安全 API 缓慢，在通过网络发送初始 SYN 数据包之前调用。
检查 SQL 网络分析器的临时端口报告，并确保客户端未耗尽出站端口。
如果客户端在发送 SYN 数据包之前有很长的延迟，你可能会看到一种模式，其中仅显示 TCP 3 向打开握手、紧跟在发送 PreLogin 数据包之后，或者有时发送来自客户端的 ACK+FIN 数据包之后。
收集网络跟踪和 BID 跟踪，以隔离 Windows 上的客户端问题
打开SQLTrace.ini文件并重新打开以下设置：
BIDTrace=Yes、AuthTrace=Yes和EventViewer=Yes配置
BIDProviderListin SQLTrace.ini 以匹配应用程序正在使用的驱动程序。.NET System.Data.SqlClient默认为启用状态。 如果不是使用的驱动程序，请通过添加到#行的前面将其从 ODBC 或 OLEDB 列表的开头删除来禁用BIDProviderList。 这将捕获该类型的所有受支持的驱动程序。 有关详细信息，请参阅 INI 配置。保存文件。
以管理员身份打开 PowerShell，并将目录更改为包含 SQLTrace.ps1 的文件夹。
CD C:\MSDATA初始化 BID 跟踪注册表（如果收集 BID 跟踪）。
注意
默认情况下启用 BID 跟踪。
.\SQLTrace.ps1 -setup重启要跟踪的服务或应用程序。
对于某些应用程序（如 SQL Server Integration Services（SSIS）包，运行包时会启动 DTEXEC 或 ISServerExec 的新实例，因此重启没有意义。
启动跟踪集合。
.\SQLTrace.ps1 -start重现问题或等待错误发生。
停止跟踪。
.\SQLTrace.ps1 -stop
输出文件夹在当前目录中生成，你可以使用它进行进一步分析。
若要跟踪其他Microsoft SQL Server 驱动程序，请参阅以下文章。 使用网络跟踪执行。
- Linux 和 Mac ODBC 驱动程序 BID 跟踪
- 收集 .NET Core SQL 驱动程序跟踪
- 下载 PerfView
- 使用 PerfView 收集跟踪日志
- Microsoft JDBC 驱动程序
若要跟踪第三方驱动程序，请参阅供应商文档。
服务器跟踪和客户端跟踪都同意问题位于服务器上
如果两个跟踪在服务器上显示延迟或无响应，或者服务器在登录序列中的意外点关闭连接，或者服务器同时关闭许多连接，则表示服务器上存在一些问题。
最可能的原因是服务器性能不佳、MAXDOP 高以及大型并行查询和阻塞。 这可能会导致线程饥饿，从而防止及时处理登录请求，尤其是当许多连接超时同时结束并且 LoginAck 列显示“延迟”。SQL Server ERRORLOG 文件可能会显示 IO 操作花费的时间超过 15 秒，这是性能问题的另一个指标。 在网络跟踪中，你可能还会在重置报告中看到包含六个帧或更少帧的许多对话，表明 TCP 3 向握手可能尚未完成。 有关详细信息，请参阅 “收集连接环缓冲区”。
RingBufferConnectivity运行查询并将结果粘贴到 Excel 中。 由于这是历史列表，因此可以在问题发生后运行。 但是对于繁忙的服务器，它可能会很快结束。 对于慢速服务器，它可能有几天的数据。
如果应用程序使用多个活动结果集（MARS），它将以 RESET 结尾，作为结束序列的一部分。 如果已从客户端发送 SMP：FIN 和 ACK+FIN 数据包，则这是良性的。 服务器的 SMP：FIN 数据包将在客户端的 ACK+FIN 之后到达，Windows 将发出 ACK+RESET，然后在连接关闭序列中为任何其他服务器响应发出 RESET。
连接池
有关详细信息，请参阅 连接池。
如果使用连接池，则网络跟踪中的对话通常相当长。 可以使用 SQL Server 网络分析器生成的 CSV 文件按协议和帧进行排序和筛选。 如果网络捕获不到半小时，则可能不会看到开始或结束帧。 如果许多会话比 SYN 数据包到 ACK+FIN 数据包的帧短于 30 帧，则表示非共用连接。 如果这些会话与较长的对话混合，则在读取结果集时对非 MARS 连接执行命令导致的可疑后台非共用连接。
临时端口报告将显示跟踪生存期内的新连接数。 可以按每秒连接数来判断连接速率。
RESET 与 ACK+RESET
应用程序或 Windows 中止连接时，通常会看到 ACK+RESET。 这通常是由于低级别 TCP 错误造成的。 数据包通知其他计算机立即停止发送。 但是，如果服务器处于传输阶段，发送 ACK+RESET 后，一两个数据包可能会到达客户端。 由于端口已关闭，操作系统会发送 RESET 数据包。 如果数据包在非正常关闭握手的 ACK+FIN 数据包之后到达，也会发生这种情况。
某些第三方驱动程序还会发送 ACK+RESET 数据包来关闭连接，而不是 ACK+FIN。 某些探测连接也可以执行此操作。 如果 ACK+RESET 数据包前面没有 Keep-Alive 数据包、重新传输的数据包或零 Windows 数据包，并且当正常关闭 ACK+FIN 时，它来自客户端，这可能是良性的。
使用 NETSTAT 分析网络问题
运行 SQLTrace.ps1 进行数据收集时，会自动收集 NETSTAT。
或者，你可以以管理员身份在命令提示符中运行NETSTAT -abon > c:\ports.txt，以收集与网络问题相关的信息。
ports.txt文件将包含所有入站和出站端口、端口号、进程 ID 以及拥有端口的应用程序的名称的列表。 你可以使用它来查看最坏的罪犯以及港口限制是否已达到。 在记事本中打开 状态栏 并关闭 换行。 状态栏将提供行计数。 可以除以两个来获取近似端口使用量。
调整 TcpTimedWaitDelay 和 MaxUserPort
如果应用程序耗尽了主机上的出站端口，并且无法立即对应用程序进行任何更改，则可以从 240 减少 TcpTimedWaitDelay 到 30 秒，从而更快地回收出站端口。
对于 Windows 2003 及更高版本，还可以增加 。MaxUserPort 对于 Windows Vista 及更高版本，可以通过命令设置此设置 NETSH 。 此操作过程不会消除非共用连接或非入池后台连接的低效，因此应强烈建议开发人员更改其应用程序以使用连接池。
对于 Windows 2008 及更高版本，该范围默认从大约 4,000 个临时端口增加到 16,000 个端口。
有关详细信息，请参阅 调整 MaxUserPort 和 TcpTimedWaitDelay 设置。
与防病毒或网络筛选器驱动程序相关的问题
几乎所有从客户端发送到服务器或服务器到客户端的数据包都以相反的方向响应 ACK 数据包。 TCP.SYS层生成 ACK。 如果在客户端上收到数据包，并且客户端跟踪显示它传入但未返回 ACK 服务器，则表明防病毒或其他网络筛选器驱动程序已丢失或删除数据包或长时间保留数据包（超过网络跟踪收集的末尾）。 同样，如果服务器跟踪显示来自客户端但未将 ACK 发送回客户端的数据包，则表示服务器上的服务器防病毒可能存在问题。
但是，上传或下载大量数据时，ACK 数据包可能在一系列数据包之后提供，以帮助进行流控制。
防病毒和筛选器驱动程序很难证明为罪魁祸首。 几乎总是需要经验测试。 在防病毒中为应用程序或 SQL Server 创建异常，然后监视它 48 小时，以查看行为是否得到改善。 如果无法设置异常，请卸载防病毒程序并重新启动。 禁用它通常无济于事，因为防病毒筛选器驱动程序仍将加载。 只有在边缘保护已到位时，才能这样做。
咨询网络安全管理员。 如果情况有所改善，可能需要与防病毒供应商合作来缓解该问题。 否则，其他网络筛选器驱动程序可能是罪魁祸首。
启用 Windows 防火墙审核
若要确定防火墙是否已删除任何数据包， 请启用 Windows 中的防火墙审核。
对于 SQL Server，此问题可能与客户端或服务器计算机相关。 网络跟踪将显示计算机收到数据包但未响应。 然后，可以重新传输数据包，再次没有响应，并最终重置连接。
经验和其他操作
临时端口
耗尽临时端口是间歇性连接超时的相对常见原因，尤其是在网络上看不到 SYN 数据包时。
对于服务器上的传入请求，端口（例如 80 或 1433）每个客户端 IP 地址最多可能需要 64,000 个传入连接，并且对于所有实际目的，通常为“无限制”。
对于出站连接，另一方面，端口数有限，并且在所有服务器连接之间共享。 对于 Windows Vista、Windows 2008 及更高版本，默认范围为端口 49152 到 65535（2^16 = 16,384 端口）。
通常，端口由操作系统保留 4 分钟（240 秒），然后才能被回收，并允许应用程序重复使用。 这是为了防止恶意软件的端口欺骗或意外重定向到该端口以前的持有者的新连接。 由于此延迟，在 Windows 2003 上，客户端应用程序每秒只能建立 17 个到 SQL Server 的连接，出站端口范围在不到四分钟内耗尽。 对于 Windows Vista，该数字增加到每秒 68 个连接。
对于 IIS 等应用程序，每个 HTTP 客户端可能都有一个到 SQL Server 的传出端口。 对于繁忙的 Web 服务器，当负载较高时，出站端口不足是一种现实可能性。 Web 场可以缓解这种情况。
调整最大服务器内存（MB）
若要解决与低内核内存相关的问题，请调整最大服务器内存（MB）。
禁用卸载
出于测试目的，可以通过管理命令提示符禁用某些卸载：
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled
除非这些设置缓解了问题，否则不要长时间禁用这些设置。 默认情况下，应在 Windows 2008 及更高版本上启用它们。
对于其他卸载，必须转到网络适配器属性才能查看和禁用它们。
VMware 网络缓冲区问题
包含虚拟机（VM）的 ESX 主机有一个小的网络缓冲区，如果流量激增，可能会导致可靠性问题。 以下 VMware 文章介绍如何增加缓冲区大小。 无需重启。 必须在 ESX 主机计算机上而不是 VM 上执行此操作。
在 ESXi 中使用 VMXNET3 在来宾 OS 中丢失大型数据包
此外，请尝试将 VM 移动到其他 ESX 主机服务器，或将客户端和服务器移到同一 ESX 主机服务器，并查看问题是否消失。 如果确实存在，则这是一个基本网络问题。
VMware 快照
检查错误期间发生的 VMware 快照并禁用它们。
在主机上禁用的接收端缩放 （RSS）
禁用 RSS 后，SQL Server 主机仅使用单个 CPU 来处理所有网络请求。 即使其他 CPU（和整体 CPU）级别较低，这也可能使 CPU 峰值达到 100%，并导致问题。
有关详细信息，请参阅 接收端缩放 和 接收端缩放版本 2（RSSv2）简介。
详细信息
第三方信息免责声明
本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。