共用方式為

收集數據以針對 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位址為何？

  • 計算機的網域狀態為何？ 如果已加入網域，功能變數名稱為何？

  • 使用哪個應用程式運行時間環境？ 例如，Internet Information Services (IIS) 、Windows Forms、Web Sphere 或 SQL Server Integration Services (SSIS) 作業。

  • 使用哪一種應用程式語言？

  • 使用的連接字串為何？

  • 使用哪種類型的驗證來連線到伺服器？ 例如，New Technology LAN Manager (NTLM) 、Kerberos、SQL 或 Azure Active Directory (AAD) 。

  • 如果應用程式是伺服器或服務，它會將使用者認證委派給後端資料庫嗎？

  • 是否使用限制委派？

  • 什麼是應用程式服務帳戶和網域？

  • 使用哪種類型的服務？ 它是實體、虛擬還是雲端？ 例如，IaaS、Web 應用程式、Web 角色或 Power BI。

  • 什麼是客戶端驅動程式？ 它是 Java Database Connectivity (JDBC) ，還是在 Linux 或 Mac 上執行？

    注意事項

    工作流程目前更以 Windows 為導向。

  • 此問題只會影響舊版提供者，例如 Provider=SQLOLEBD 或 Driver={SQL Server}，而不會影響 SQL Native Client 和更新版本的驅動程式， (或反之亦然) ？

  • 問題只發生在一個應用程式或多個應用程式中？

  • 當通用數據連結 (UDFL) 檔案嘗試連線到其他 SQL Server 型伺服器時，該檔案會失敗，還是只無法連線到有問題的伺服器？

  • 使用者是否登入以 SQL Server 為基礎的伺服器，並嘗試使用 SQL Server Management Studio (SSMS) 進行連線？

  • 只有在您使用伺服器的 NETBIOS 名稱，而不是當您使用完整域名 (FQDN) (或反之亦然) 時，才會發生此問題？ 是否可使用IP位址來運作？

  • 執行 Windows 10 Enterprise 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) ) 或 PaaS (Azure SQL Database、SQL 受控實例 (MI) ) 中的 SQL。
  • 資料庫是否部署為獨立、叢集、鏡像或使用Always On？
  • 什麼是故障轉移夥伴名稱和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 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。