通过

收集数据以排查 SQL Server 连接问题

  • 项目

本文通过根据特定类别提出相关问题，帮助你确定 SQL Server 连接问题的根本原因。 尽管针对 SQL Server 连接问题进行故障排除的建议先决条件和清单文章包含要收集的最重要的项，但本文中的问题可以帮助你缩小连接问题的原因范围，并有效地对其进行故障排除。

注意

并非所有问题都适用于所有问题。 但是，在考虑如何排查连接问题时，这些问题可指导你。

使用本文中提供的信息，一旦能够从零开始了解问题的确切性质，请参阅 SQL Server 中一致的身份验证问题概述，了解错误类型。

收集数据的方法

若要收集数据，可以使用问题步骤记录器（PSR）、网络跟踪和 NETLOGON 跟踪等工具。 本部分提供安装和配置所有这些工具组合的详细步骤。

在客户端和服务器计算机上同时执行这些步骤。 如果应用程序是 3 层或 n 层体系结构，则也会在中间服务器上运行安装。

  1. 在所有受影响的计算机上安装 WireShark 或使用内置NETSH命令（Windows 2008 或更高版本）。 无需重启。

  2. 运行以下命令，在客户端和所有服务器上启用 NETLOGON 调试日志记录：

    NLTEST /DBFLAG:2080FFFF

  3. 如果可能，请执行以下步骤之一：

    • 重新启动客户端计算机。
    • 要求用户注销并再次登录。
    • 关闭并重新打开客户端应用程序。

  4. 在客户端计算机上，启动 问题步骤记录器 （psr.exe），然后选择“ 开始记录”。

    此工具准确捕获问题前面的所有用户操作，并将结果保存到.zip文件中。

  5. 在所有计算机上启动网络捕获。

  6. 如果使用 NETSH，请运行 NETSH TRACE START CAPTURE=YES TRACEFILE=C:\TEMP%computername%.ETL 命令（使用适当的文件或路径名称）。

  7. 通过运行 IPCONFIG /FLUSHDNS 命令在所有计算机上刷新域名系统（DNS）缓存。

  8. 通过运行 NBTSTAT /RR 命令清除所有计算机上的 NETBIOS 缓存。

  9. 通过运行以下命令 KLIST purge 清除客户端 Kerberos 票证。

  10. 通过运行 KLIST -li 0x3e7 purge 命令清除每个服务器上的票证。

    注意

    键入 命令。 请勿复制并粘贴到命令行中，因为连字符可能会转换为长短划线（em） 短划线。 KLIST 区分大小写。

  11. 重现此问题。

  12. 停止psr.exe录制。

  13. 停止网络捕获。 通过运行命令 NETSH 保存记录的文件： NETSH TRACE STOP 使用有意义的名称。 例如，文件的名称可以是 SQLProd01.netmon.cap。

  14. 等待命令提示符重新出现，然后关闭窗口。 不要在出现提示之前关闭命令提示符窗口。

  15. 将 NETLOGON 日志复制到 C：\windows\debug\netlogon.log ，并为文件指定有意义的名称。 例如， SQLProd01.netlogon.log。

  16. 通过运行 NLTEST /DBFLAG:0x0 命令禁用日志记录。

收集数据以对问题进行分类

以下一组问题旨在帮助你找到问题所属的类别，从而引导你朝着正确的故障排除方向前进。 为相关问题选择每个下拉列表。

在开始询问具体问题之前，请确保满足 SQL Server 连接所需的所有先决条件。 有关先决条件的详细信息，请参阅 建议的先决条件和清单，以排查 SQL Server 连接问题。

更广泛的视角问题
  • 此问题是否仅影响数据库连接，或者它是否也影响 Web 和文件共享连接？ 许多案例都报告给 SQL Server 团队，因为它们发生在数据库服务器上。 但是，问题可能根本不与数据库相关，并且可能需要更常规的 Windows 或 Active Directory 支持。
  • 如果用户域、客户端域或服务器域不同，是否存在信任关系？ 它是外部、林、单向、双向还是无？
  • 如果所有资源都位于同一域中，连接是否正常工作？
  • 问题是间歇性的还是定期的，还是一致的？
  • 仅当多个用户使用应用程序时，才会出现问题？ 如果更多用户使用它，它是否更频繁？
  • 此问题是否仅在某一天或一周的某些时间发生？
  • 仅当正在执行备份或重新编制数据库索引时，才会出现问题？
  • 此问题是否影响多个服务器？
  • 此问题是否仅影响 n 节点群集中的一个节点？ 如果是，则考虑重新生成该特定节点可能更有效。
  • 此问题是否只影响多个客户端中的一两个客户端？ 如果是，也许重建会更有效。
  • 此问题是否仅影响命名管道，而不影响 TCP（反之亦然） ？
  • 使用 SQL Server 登录名和 TCP/IP 时是否会出现此问题？
  • 是否存在可与失败案例进行比较的工作案例？ 系统有何不同？
客户端计算机

使用以下问题收集有关客户端计算机的不同组件的数据。 此数据在识别问题时可能很有用。

  • 什么是操作系统名称、版本和版本（WinVer）？

  • SQL Server 驱动程序或提供程序的名称和版本是什么？

  • 计算机名称和 IP 地址是什么？

  • 计算机的域状态是什么？ 如果已加入域，域名是什么？

  • 使用哪种应用程序运行时环境？ 例如，Internet Information Services （IIS）、Windows 窗体、Web Sphere 或 SQL Server Integration Services （SSIS） 作业。

  • 使用哪种应用程序语言？

  • 使用连接字符串是什么？

  • 哪种类型的身份验证用于连接到服务器？ 例如，新技术 LAN 管理器（NTLM）、Kerberos、SQL 或 Azure Active Directory（AAD）。

  • 如果应用程序是服务器或服务，它将用户凭据委托给后端数据库吗？

  • 是否使用约束委派？

  • 什么是应用程序服务帐户和域？

  • 使用哪种类型的服务？ 它是物理、虚拟还是云？ 例如，IaaS、Web 应用、Web 角色或 Power BI。

  • 什么是客户端驱动程序？ 它是 Java 数据库连接（JDBC），还是在 Linux 或 Mac 上运行？

    注意

    工作流目前面向 Windows。

  • 此问题是否仅影响旧提供程序，例如 Provider=SQLOLEBD ，或者 Driver={SQL Server}，不影响 SQL Native Client 及更高版本的驱动程序（反之亦然） ？

  • 此问题是否仅在一个应用程序或多个应用程序中发生？

  • 当通用数据链接（UDL）文件尝试连接到其他基于 SQL Server 的服务器时，文件是否失败，或者它是否仅失败，但服务器没有出现问题？

  • 用户是否登录到基于 SQL Server 的服务器，并尝试使用 SQL Server Management Studio （SSMS）进行连接？

  • 仅当使用服务器的 NETBIOS 名称而不是使用完全限定域名（FQDN）（反之亦然）时，才会出现问题？ 它是否使用 IP 地址？

  • 运行 Windows 10 企业版 Edition 的客户端是否已启用 Credential Guard 功能？ 如果是，则可能会影响完整的委派方案。

日志信息

使用以下问题收集有关日志文件的数据：

  • 调用堆栈中的确切错误消息是什么？
  • 日志是从 SQL Server ERRORLOG 和 ERRORLOG.1 文件中收集的吗？
  • 应用程序事件日志是从客户端和服务器收集的吗？
  • 是否已收集客户端应用程序日志文件和配置文件？ 例如，web.config、rsreportserver.config、*.config 或 *.ini。
  • 是否存在显示计算机、路由器等的网络的可用可视表示形式？
新问题或现有问题

指确定问题是最近开发的还是持续了一段时间：

  • 问题是否始终存在（新安装），或者应用程序在最近中断之前是否正常运行了一段时间？
  • 如果应用程序用于正常运行，则对环境进行了哪些更改？ 例如，已安装的更新、升级的域控制器、防火墙设置中的更改、解除授权的域控制器或移动到域中的其他 OU。
服务器计算机

对于链接服务器，请收集中间层服务器和后端服务器的服务器信息。 对于 IIS 到 SQL 委派问题，请收集有关 Web 服务器的信息，包括 web.config 和身份验证设置。

  • 操作系统名称、版本和版本（Winver）的名称是什么？
  • 数据库的名称和版本是什么？
  • 计算机的名称是什么？
  • IP 地址是什么？
  • 如果计算机已加入域，域名是什么？
  • 什么是 SQL Server 服务帐户和域？
  • SQL Server 实例的名称是什么？
  • 已启用哪些协议？
  • 服务器侦听的端口是什么？
  • 服务器管道的名称是什么？ 可以在错误日志中找到此信息。
  • 使用哪种类型的环境？ 它是物理、虚拟还是云？ 例如，IaaS（Azure 虚拟机（VM）或 PaaS（Azure SQL 数据库，SQL 托管实例（MI））。
  • 数据库是否部署为独立数据库、群集数据库、镜像数据库或使用 Always On？
  • 什么是故障转移伙伴名称和 IP 地址？
  • 什么是虚拟群集名称或侦听器名称和端口？
  • 什么是虚拟 IP 或侦听器 IP？
  • 安装了哪个操作系统？ 是 Windows、Linux 还是 Mac？ 这可能会影响数据收集。
  • 数据库的位置是什么？ 是否在 Azure 中？
  • 服务器的最新 Service Pack 和累积更新的当前状态是什么？ 调试已修复的问题没有意义。
  • SQL Server 最近是否已升级以支持传输层安全性 （TLS） 1.2？ 客户端是否已更新？ TLS 1.0 是否已关闭？
  • SQL Server 服务的当前状态是什么？ 是否正在运行？
  • SQL Browser 服务的状态是什么？ 是否正在运行？
  • 服务帐户的问题的具体性是什么？ 使用其他服务帐户运行服务器是否解决了该问题？
用户信息

收集以下用户详细信息：

  • 用户是否直接登录到客户端计算机或远程访问它？ 例如，用户是否使用浏览器？
  • 用户是否是服务，例如 SQL 代理？ 正在使用进程标识还是正在使用存储凭据？
  • 用于连接到客户端应用程序的身份验证类型是什么？ 是 Windows、窗体身份验证还是 AAD？
  • 用户是否使用集成安全性连接到服务器？
  • 什么是用户名和域名？

如果用户远程连接到客户端应用程序，请收集以下详细信息：

  • 计算机名称和 IP 地址是什么？
  • 计算机域是否已加入？ 如果是，域名是什么？
  • 用户是通过 VPN 还是代理服务器进行连接？ 如果任一方法直接连接，是否会发生此问题？
  • 如果用户正在连接到 Web 服务器，服务器负载是否均衡？
  • 是否使用粘滞会话或会话相关性？
  • 用户是否登录到终端服务器或跳转盒并访问应用程序？
  • 此问题是否仅影响特定组织单位（OU）的用户？
  • 用户、客户端或服务器是否已移动到 Active Directory 中的其他组织单位（OU）？
  • 此问题是否仅影响非管理用户？
  • 此问题是否影响特定域中的所有用户或仅影响某些用户？

另请参阅

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。