共用方式為

收集數據以針對 SQL Server 連線問題進行疑難解答

  • 發行項

本文會根據特定類別詢問相關問題，協助您找出 SQL Server 連線問題的根本原因。 雖然針對 SQL Server 連線問題進行疑難解答的建議必要條件和檢查清單文章包含要收集的最重要專案，但本文中的問題可協助您縮小連線問題的原因，並有效地進行疑難解答。

注意

並非所有問題都適用於所有問題。 不過，當您考慮如何針對連線問題進行疑難解答時，這些問題可引導您。

使用本文中提供的資訊，一旦您能夠在問題的確切本質上以零為單位，請參閱 SQL Server 中一致的驗證問題概觀，以瞭解錯誤的類型。

收集數據的方法

若要收集數據，您可以使用問題步驟錄製器（PSR）、網路追蹤和 NETLOGON 追蹤等工具。 本節提供安裝和設定所有這些工具組合的詳細步驟。

在客戶端和伺服器電腦上同時遵循這些步驟。 如果應用程式是 3 層或多層式架構，則也會在中繼伺服器上執行安裝。

  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位址為何？

  • 計算機的網域狀態為何？ 如果已加入網域，則域名為何？

  • 使用哪個應用程式運行時間環境？ 例如，網際網路資訊服務 （IIS）、Windows Forms、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.config 和驗證設定。

  • 操作系統名稱、版本和版本 （Winver）的名稱為何？
  • 資料庫的名稱和版本為何？
  • 計算機的名稱為何？
  • 什麼是IP位址？
  • 如果計算機已加入網域，則域名為何？
  • 什麼是 SQL Server 服務帳戶和網域？
  • SQL Server 實例的名稱為何？
  • 哪些通訊協議已啟用？
  • 伺服器接聽的埠是什麼？
  • 伺服器管道的名稱為何？ 您可以在錯誤記錄檔中找到此資訊。
  • 使用哪種類型的環境？ 是實體、虛擬還是雲端？ 例如，IaaS（Azure 虛擬機（VM）中的 SQL）或 PaaS（Azure SQL 資料庫、SQL 受管理執行個體（MI））。
  • 資料庫是否部署為獨立、叢集、鏡像或使用AlwaysOn？
  • 什麼是故障轉移夥伴名稱和IP位址？
  • 什麼是虛擬叢集名稱或接聽程式名稱和埠？
  • 什麼是虛擬IP或接聽程式IP？
  • 資料庫安裝在哪個作業系統上？ 是 Windows、Linux 或 Mac 嗎？ 這可能會影響數據收集。
  • 資料庫的位置為何？ 它是在 Azure 中嗎？
  • 根據最新的 Service Pack 和累積更新，伺服器目前的狀態為何？ 偵錯已修正的問題沒有意義。
  • SQL Server 最近是否已升級以支援傳輸層安全性 （TLS） 1.2？ 用戶端也已更新嗎？ TLS 1.0 是否已關閉？
  • SQL Server 服務的目前狀態為何？ 是否正在執行？
  • SQL Browser 服務的狀態為何？ 是否正在執行？
  • 服務帳戶的問題具體性為何？ 使用不同服務帳戶執行伺服器是否可解決此問題？
用戶資訊

收集下列使用者詳細資料：

  • 使用者是否直接登入用戶端計算機，或從遠端存取用戶端電腦？ 例如，使用者是否使用瀏覽器？
  • 使用者是否為服務，例如 SQL Agent？ 正在使用的進程身分識別，還是正在使用預存認證？
  • 用來連線到用戶端應用程式的驗證類型為何？ 是 Windows、Forms 驗證還是 AAD？
  • 使用者是否使用整合式安全性連線到伺服器？
  • 用戶名稱和域名為何？

如果使用者是用戶端應用程式的遠端，請收集下列詳細資料：

  • 計算機名稱和IP位址為何？
  • 計算機已加入網域嗎？ 如果是，域名是什麼？
  • 使用者是否透過 VPN 或 Proxy 伺服器連線？ 如果任一種方法直接連接，就會發生此問題嗎？
  • 如果使用者正在連線到網頁伺服器，伺服器是否負載平衡？
  • 是否使用黏性會話或會話親和性？
  • 使用者是否登入終端機伺服器或跳躍方塊並存取應用程式？
  • 此問題是否只影響特定組織單位 （OU） 的使用者？
  • 使用者、客戶端或伺服器是否已移至 Active Directory 中的不同組織單位 （OU？
  • 此問題是否只影響非系統管理使用者？
  • 此問題是否會影響特定網域中的所有或只有部分使用者？

另請參閱

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。