針對連線到 SQL Server 的間歇性或定期問題進行疑難解答

總結

本文說明如何排除間歇性或週期性導致 SQL Server 連線失敗、逾時或意外重置的網路相關問題。 它描述了最常見的錯誤訊息、根本原因（例如遺失封包、防毒過濾器或耗盡的臨時埠口），以及基於 SQLCHECK、SQLTRACE 和網路追蹤分析（SQLNA）的資料驅動故障排除流程。 用它來判斷問題出在用戶端、伺服器，還是它們之間的網路路徑。

間歇性 SQL Server 連線問題常見錯誤訊息

間歇性問題不規則發生，而定期問題通常會以可預測的間隔發生。 識別問題類型是疑難解答的第一個步驟。 當間歇性或週期性 SQL Server 連線問題發生時，您可能會遇到以下錯誤訊息：

• 通訊連結失敗：此錯誤表示網路元件之間的通訊中斷。
• 連線逾時：與伺服器的連線已逾時，表示伺服器回應延遲或無法使用。
• 一般網路錯誤：一般網路錯誤訊息通常表示網路未指定的問題。
• 傳輸層錯誤：此錯誤發生在傳輸層，表示資料傳輸可能有問題。
• 指定的網路名稱已無法使用：此訊息表示無法連線到指定的網路資源。
• 號誌逾時：此錯誤表示與網路中使用號誌有關的逾時情況。
• 等候作業逾時：等候作業已超過其允許的時間，通常是因為網路延遲。
• 從網路讀取輸入串流時發生嚴重錯誤：此訊息表示從網路讀取資料時發生了嚴重錯誤。
• TDS 資料流中的通訊協定錯誤：表格式數據流 （TDS） 是 SQL Server 所使用的通訊協定。 此錯誤表示通訊協議發生問題。
• 找不到伺服器或無法存取：此錯誤訊息表示您嘗試存取的伺服器無法使用或找不到。
• SQL Server 不存在或拒絕存取：此錯誤可能表示 SQL Server 不存在，或嘗試存取 SQL Server 時發生驗證錯誤。

SQL Server 間歇性連線問題的常見原因

最常見的問題包括因防毒軟體、網路優化、過時的網路驅動程式、不良的路由器或交換器，以及應用程式中未被池化的連線所造成的封包遺失。

部分原因，如防毒軟體，雖然難以證明，但仍屬常見現象。 你可能需要先卸載軟體並重開電腦來證明，沒有明確證據。 為 SQL Server 建立例外也可能有效。 但關閉防毒軟體通常沒用，因為網路過濾器驅動程式即使沒被監控也會載入。

疑難排解程序

一般來說，故障排除應該以資料為導向，這可能會讓位於更聚焦的實證測試。 如果問題非常間歇且網路痕跡難以捕捉，請先應用 實證方法 。

在每部計算機上使用 SQLCHECK 收集報表

在每個電腦上執行 SQLCHECK 以產生報表。 判斷連線故障的原因很有幫助。

收集客戶端和伺服器上的網路追蹤

• 在 Windows 電腦上，使用 SQLTRACE 收集網路追蹤。

  請依照下列步驟準備並執行追蹤。 步驟 2 和 3 只需要完成一次。

  1. 下載最新版本的 SQLTRACE ，並將其解壓縮到資料夾，例如 C：\MSDATA。

  2. 開啟SQLTrace.ini檔案，然後關閉下列設定：

     BIDTrace=no、AuthTrace=no 和 EventViewer=no

  3. 儲存檔案。

  4. 以系統管理員身分開啟 PowerShell，並將目錄變更為包含 SQLTrace.ps1 的資料夾。

     CD C:\MSDATA
     

  5. 開始收集追蹤資料。

     .\SQLTrace.ps1 -start
     

  6. 重現問題，或等候錯誤發生。

  7. 停止追蹤。

     .\SQLTrace.ps1 -stop
     

  此程序會在目前目錄中建立一個輸出資料夾。 請使用此資料夾進行進一步分析。

• 在非 Windows 電腦上，使用 TCPDUMP 或 WireShark 擷取封包。

執行 SQL Server 網路分析器

SQL 網路分析器 UI （SQLNAUI） 提供圖形化介面，以選取追蹤檔案以進行剖析和設定選項。 從 SQL 網路分析器 （SQLNA） 下載它。

個別處理客戶端和伺服器追蹤。 如果您有串連的追蹤，請同時處理它們。 這些檔案的總大小不應超過您計算機的記憶體的80%。 請確定您有足夠的記憶體來處理所有相關的追蹤檔案。

此工具會產生可疑問題報告，以及您可以在 Excel 中探索的 CSV 檔案以進行替代研究。

嘗試在客戶端追蹤和伺服器追蹤中找出相符的交談。 一般而言，IP 位址和埠號碼相符。 不過，如果這些連線經過任何形式的網路位址轉譯或連接埠對應，情況可能會更棘手，而您可能得利用 IPv4 封包識別碼來對齊並比較酬載。

在網路追蹤分析中尋找的模式

檢查對話在 NETMON 或 WireShark 中是如何結束的。 檢查客戶端和伺服器是否同意相同專案，或他們是否講述不同的故事。

連線在 SSL 交握期間關閉

在 ServerHello 封包中，如果使用的加密套件是 Diffie-Hellman 套件，且流量介於 Windows 2012 或更早版本與 Windows 2016 或更新版本之間，則此演算法會從 Windows 2016 安全性修補程式開始變更。 您應該停用此加密套件群組。 如需詳細資訊，請參閱 Windows 中連線 SQL 伺服器時，應用程式遇到強制關閉的 TLS 連線錯誤。

如果在 ClientHello 之後關閉連線，請檢查客戶端與伺服器之間是否有 TLS 1.0 或 TLS 1.2 不符。 如果相同，請檢查兩部機器上已啟用的加密套件和已啟用哈希。

如需詳細資訊，請參閱 進階安全套接字層數據擷取。

遺失的封包

查看符合條件的對話結尾。 如果其中一方有許多重傳封包（或 10 個相隔 1 秒的 Keep-Alive 封包），接著出現 ACK+RESET，而另一方沒有；或者其中一方回報及時回應，而另一方觀察到該回應延遲，並關閉或重設連線，這表示網路裝置有問題，且封包遭到丟棄或延遲。

您可能也會看到用戶端報表，指出伺服器重設交談，而伺服器報表則表示用戶端重設交談。 這通常是因為有問題的交換器或路由器從中間切斷了連線；如果這些設備偵測到連線已閒置一段時間，有時會被設定為這麼做，而且通常會忽略 Keep-Alive 封包。

如需已卸除連線的詳細資訊，請參閱：

• 雙向連線中斷
• 連線在單一方向中斷
• 單向單邊追蹤中斷連線
• 網路裝置重設連線

伺服器追蹤和客戶端追蹤都同意問題位於用戶端上

如果兩份追蹤記錄都顯示用戶端發生延遲或沒有回應，或者用戶端在確認收到伺服器回應後送出 ACK+RESET，或在登入流程期間過早關閉連線，您就需要在用戶端上擷取 BID 追蹤和 NETSH 追蹤，以深入檢查 TCP/IP 通訊協定堆疊，並瞭解驅動程式的處理情況。 如果防病毒軟體或其他網路篩選驅動程序延遲接收封包或傳送回復，則很常見。 連線逾時也可能是因為在透過網路傳送初始 SYN 封包之前所呼叫的 DNS 回應過慢，或安全性 API 處理過慢。

檢查 SQL 網路分析器的暫時埠報告，並確定用戶端未用完輸出埠。

如果客戶端在傳送 SYN 封包前延遲很久，您可能會看到一種模式：只出現 TCP 三向交握，接著立即，或有時在傳送 PreLogin 封包之後，出現由客戶端發出的 ACK+FIN。

收集網路追蹤和 BID 追蹤，以隔離 Windows 上的客戶端問題

1. 開啟SQLTrace.ini檔案，然後重新開啟下列設定：

   BIDTrace=Yes、AuthTrace=Yes 和 EventViewer=Yes

2. 在 BIDProviderList 中設定 ，使其符合您的應用程式所使用的驅動程式。

   .NET System.Data.SqlClient 預設為啟用。 如果那不是您正在使用的驅動程式，請在該行前面加上 BIDProviderList 以停用 #，並將它從 ODBC 或 OLEDB 清單的開頭移除。 這會擷取該類型的所有支持驅動程式。 如需詳細資訊，請參閱 INI 組態。

3. 儲存檔案。

4. 以系統管理員身分開啟 PowerShell，並將目錄變更為包含 SQLTrace.ps1 的資料夾。

   CD C:\MSDATA
   

5. 如果要收集 BID 追蹤，請初始化 BID 追蹤登錄檔。

   附註

   默認會啟用 BID 追蹤。

   .\SQLTrace.ps1 -setup
   

6. 重新啟動您要追蹤的服務或應用程式。

   對於某些應用程式，例如 SQL Server Integration Services （SSIS） 套件，在執行封裝時會啟動 DTEXEC 或 ISServerExec 的新實例，因此重新啟動並無意義。

7. 開始收集追蹤資料。

   .\SQLTrace.ps1 -start
   

8. 重現問題，或等候錯誤發生。

9. 停止追蹤。

   .\SQLTrace.ps1 -stop
   

此程序會在目前目錄中建立一個輸出資料夾。 請使用此資料夾進行進一步分析。

若要追蹤其他Microsoft SQL Server 驅動程式，請參閱下列文章。 使用網路追蹤執行。

• Linux 和 Mac ODBC 驅動程式 BID 追蹤
• 收集 .NET Core SQL 驅動程式追蹤記錄
• 下載 PerfView
• 使用 PerfView 收集追蹤記錄
• Microsoft JDBC 驅動程式

若要追蹤第三方驅動程式，請參閱廠商檔。

伺服器追蹤和客戶端追蹤都同意問題位於伺服器上

如果這兩個追蹤在伺服器上顯示延遲或沒有回應，或者如果伺服器在登入順序中的非預期點關閉連接，或伺服器同時關閉許多連線，這表示伺服器上有一些問題。

最可能的原因是伺服器效能不佳、高 MAXDOP、大量平行查詢以及阻塞。 這些狀況可能導致執行緒飢餓，導致認證請求無法及時處理，尤其當多個連線逾時同時結束且 LoginAck 欄位顯示「Late」時。SQL Server 的 ERRORLOG 檔案可能顯示 IO 操作超過 15 秒，這也是效能問題的另一個指標。 在網路追蹤中，你也可能會在重設報告中看到許多影格數不超過六個的連線，這表示 TCP 三向交握可能尚未完成。 如需更多資訊，請參閱 收集連線環形緩衝區資料。

執行查詢， RingBufferConnectivity 並將結果貼到 Excel 中。 由於這個清單是歷史資料，你可以在問題發生後再執行。 但對繁忙的伺服器來說，它可能很快就會結束。 對於速度較慢的伺服器，它可能會保有兩天左右的資料。

如果您的應用程式使用多個作用中結果集 (MARS)，則在關閉程序中會以 RESET 結尾。 如果已從用戶端傳送SMP：FIN 和 ACK+FIN 封包，則這是良性的。 伺服器的 SMP：FIN 封包會在用戶端的 ACK+FIN 之後抵達，而 Windows 會發出 ACK+RESET，然後針對任何其他伺服器回應發出 RESET 作為連線關閉順序的一部分。

連線共用

如需詳細資訊，請參閱 連線共用。

如果你使用連線池，網路追蹤中的對話通常會相當長。 您可以使用 SQL Server 網路分析器所產生的 CSV 檔案，依通訊協議和畫面格排序和篩選。 如果網路擷取時間少於半小時，你大概看不到開始或結束的影格。 如果從 SYN 封包到 ACK+FIN 封包的多個會話短於 30 幀，則表示連線未被合併。 如果這些非池連線與幾段較長的對話混合，懷疑背景非池連線是因為在讀取結果集時執行指令而產生。

暫時連接埠報告會顯示在追蹤期間建立的新連線數量。 您可以依每秒的連線數目來判斷連線速率。

RESET 與 ACK+RESET

通常當應用程式或 Windows 中止連線時，你會看到 ACK+RESET 的結果。 此狀況通常是由低階 TCP 錯誤引起。 封包會通知其他電腦立即停止傳送。 然而，如果伺服器正在傳輸中，ACK+RESET 傳送後，可能會有一兩個封包抵達用戶端。 由於埠已關閉，操作系統會傳送 RESET 封包。 如果封包在 ACK+FIN 封包之後抵達，且不屬於正常的成交握手，也會出現這種情況。

某些第三方驅動程式也會傳送 ACK+RESET 封包來關閉連線，而不是 ACK+FIN。 有些探針連接也能執行此動作。 如果 ACK+RESET 封包之前沒有 Keep-Alive 封包、重傳封包或零視窗封包，且在原本預期應出現正常的 ACK+FIN 關閉時，該封包卻是由用戶端送出，則它可能屬於無害情況。

使用 NETSTAT 分析網路問題

當你執行資料收集 SQLTrace.ps1 時，NETSTAT 會自動被收集。

或者，你可以以管理員身份在NETSTAT -abon > c:\ports.txt執行，收集與網路問題相關的資訊。

ports.txt 檔案包含所有進出埠的清單、埠號、程序 ID 以及擁有這些埠的應用程式名稱。 使用此清單查看最嚴重的違規者及是否已達到埠口限制。 在記事本中開啟 狀態列，然後關閉 自動換行。 狀態列會顯示行數。 您可以除以兩個來取得大約的埠使用量。

調整 TcpTimedWaitDelay 與 MaxUserPort

如果某個應用程式耗盡了主機上的輸出連接埠，而您又無法立即變更該應用程式，則可以將 TcpTimedWaitDelay 從 240 秒調降至最低 30 秒，讓輸出連接埠能更快重新回收利用。

你也可以透過使用 netsh int ipv4 set dynamicport tcp （或 ipv6）指令來擴大主機上的動態用戶端埠範圍。 此舉無法消除非集區連線或非集區背景連線所造成的低效率。 理想狀況下，應用程式應改為使用連線池。

目前支援的 Windows 版本已使用 IANA 標準的預設動態用戶端埠範圍 49152 至 65535，提供約 16,384 個臨時埠口。

如需詳細資訊，請參閱 調整 MaxUserPort 和 TcpTimedWaitDelay 設定。

與防病毒軟體或網路篩選驅動程式相關的問題

幾乎所有從用戶端傳送到伺服器或伺服器到用戶端的封包都會以相反方向的 ACK 封包來回應。 TCP.SYS層會產生 ACK。 如果用戶端收到封包，且用戶端追蹤顯示封包已進入，但伺服器未收到 ACK，這通常是防毒軟體或其他網路過濾驅動程式遺失、遺失封包或長期保留封包（超過網路追蹤收集結束後）。 同樣地，如果伺服器追蹤顯示有封包從用戶端傳送，但沒有回傳 ACK，這表示伺服器上的防毒軟體可能有問題。

然而，當上傳或下載大量資料時，ACK 封包可能會在一連串資料封包之後出現，以協助流量控制。

要證明防毒軟體和過濾驅動程式是罪魁禍首非常困難。 你幾乎總是需要做實證測試。 在防病毒軟體中建立應用程式或 SQL Server 的例外狀況，然後監視它 48 小時，以查看行為是否改善。 如果無法設定例外，請解除安裝防毒軟體並重新啟動。 停用它通常無濟於事，因為防病毒軟體篩選驅動程式仍會載入。 只有在邊緣保護已到位時，才應將此作為最後手段。

請洽詢您的網路安全性系統管理員。 如果情況改善，你可能需要與防毒廠商合作來減輕問題。 如果沒有，其他網路篩選驅動程式可能是罪魁禍首。

啟用 Windows 防火牆稽核

要判斷防火牆是否會丟棄封包，請在 Windows 啟用防火牆稽核。

針對 SQL Server，此問題可能與用戶端或伺服器電腦有關。 網路追蹤會顯示電腦收到封包但未回應。 接著可以重新傳輸封包，再次取得沒有回應，最後會重設連線。

實證和其他操作

暫時連接埠

暫時連接埠耗盡，是造成間歇性連線逾時的較常見原因之一，特別是當您未在線路上看到 SYN 封包時。

對於伺服器上的傳入要求，80 或 1433 等連接埠可針對每個用戶端 IP 位址處理多達 64,000 個傳入連線，且實際上通常可視為不受限制。

對於出站連線，埠數有限，且所有伺服器連線共用。 在目前支援的 Windows 版本中，預設的動態用戶端埠範圍為 49152 至 65535，約提供 16,384 個臨時埠。

通常，作業系統會保留埠口四分鐘（240秒）後回收並允許應用程式重複使用。 此延遲可防止惡意軟體進行埠口偽造，或誤將新連線重定向至該埠的前持有者。 由於此延遲，使用預設動態埠範圍及預設 TcpTimedWaitDelay 240 秒的用戶端應用程式，每秒只能開啟約 68 個新的 SQL Server 外站連線，之後就會耗盡約 16,384 個臨時埠口。 藉由使用 TcpTimedWaitDelay 來降低 netsh int ipv4 set dynamicport tcp，或擴大動態連接埠範圍，都會提高該上限。

對於像 IIS 這類應用程式，每個 HTTP 用戶端可能有一個輸出埠到 SQL Server。 對於忙碌的網頁伺服器，當負載很高時，輸出埠不足是一種實際的可能性。 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 版本預設會啟用這些功能。

若要進行其他卸除，您必須移至網路適配器屬性以檢視和停用它們。

VMware 網路緩衝區問題

包含虛擬機 （VM） 的 ESX 主機具有小型網路緩衝區，如果流量暴增，可能會導致可靠性問題。 下列 VMware 文章說明如何增加緩衝區大小。 不需要重新啟動。 此作業必須在 ESX 主電腦上完成，而不是 VM。

在 ESXi 中使用 VMXNET3 時，客體作業系統出現大量封包遺失

此外，請嘗試將 VM 移至不同的 ESX 主機伺服器，或將用戶端和伺服器移至相同的 ESX 主機伺服器，並查看問題是否消失。 如果確實如此，那就是底層網路問題。

VMware 快照集

檢查在發生錯誤期間是否有 VMware 快照，並停用它們。

主機上的接收端縮放 (RSS) 已停用

停用 RSS 時，SQL Server 主機只會使用單一 CPU 來處理所有網路要求。 這可能會使 CPU 使用率飆升至 100%，並導致問題，即使其他 CPU 的使用率（以及整體 CPU 使用率）都很低也一樣。

如需詳細資訊，請參閱 接收端調整 和 接收端調整第 2 版（RSSv2）簡介。

相關內容

• SQL Server 中的間歇性或定期驗證問題
• 建議的先決條件與檢查清單，用於排除 SQL Server 連線問題
• 針對 SQL Server 中的連線問題進行疑難排解
• 收集網路追蹤記錄

協力廠商資訊免責聲明

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