通过

收集数据以排查 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 命令清除每个服务器上的票证。

    注意

    键入 命令。 请勿复制并粘贴到命令行，因为连字符可能会转换为长 (，) 短划线。 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 企业版的客户端是否已启用 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 浏览器服务的状态是什么？ 是否正在运行？
  • 服务帐户问题的具体性是什么？ 使用其他服务帐户运行服务器是否解决了此问题？
用户信息

收集以下用户详细信息：

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

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

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

另请参阅

第三方信息免责声明

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