針對整個 SQL Server 或資料庫應用程式似乎執行緩慢的問題進行疑難排解

適用於：SQL Server

當您對 SQL Server 實例或特定應用程式執行查詢時，所有查詢都會變慢。 若要解決此問題，請遵循下列步驟：

步驟 1：針對應用程式問題進行疑難解答

檢查應用層。 從應用程式取得查詢、在 SQL Server 實例上手動執行查詢，並查看其執行方式。 以這種方式測試數個查詢。 如果 SQL Server 實例上的查詢速度較快，問題可能位於應用程式或應用程式伺服器的層上。

注意

請注意 資料庫應用程式和 SSMS 之間的查詢效能差異。

如果應用程式在不同的伺服器上執行，請檢查應用程式伺服器的效能（請參閱 步驟 2：針對 OS 問題 進行疑難解答以取得疑難解答）。 您可能需要與應用程式開發小組連絡，以檢查應用程式是否有任何問題。

步驟 2：針對操作系統問題進行疑難解答

檢查 SQL Server 執行所在的作業系統是否回應緩慢。 例如，滑鼠移動速度緩慢，視窗不會回應很長一段時間、伺服器的遠端桌面存取速度很慢，或連線到伺服器上的共用速度很慢。

此問題可能是由另一個服務或應用程式所造成。 使用 Perfmon 進行疑難解答。

如需其他OS效能問題，請參閱 Windows Server 效能疑難解答檔。

常見問題包括：

此問題可能是由系統上執行的其他應用程式、OS 或驅動程式所造成。

若要針對此問題進行疑難解答，請使用任務管理器、效能監視器 或資源監視器來識別此問題。 如需詳細資訊，請參閱 高 CPU 使用量疑難解答指引。

步驟 3：針對網路問題進行疑難解答

問題可能位於網路層中，導致應用程式與 SQL Server 之間的通訊速度緩慢。 使用下列方法來針對此問題進行疑難解答：

  • 其中一個徵兆可能是 ASYNC_NETWORK_IO 在 SQL Server 端等候。 如需詳細資訊，請參閱 針對ASYNC_NETWORK_IO等候類型所產生的慢速查詢進行疑難解答。

  • 請與您的網路管理員合作，檢查網路問題（防火牆、路由等等）。

  • 收集網路追蹤，並檢查網路重設和重新傳輸事件。 如需疑難解答構想，請參閱 間歇性或定期網路問題。

  • 啟用 Perfmon 計數器，以檢查網路介面層級 （NIC） 的網路效能。 應該會有零個捨棄的封包和錯誤封包。 檢查網路介面頻寬：

    • 已捨棄的網路介面\封包
    • 網路介面\封包收到錯誤
    • 網路介面\封包輸出捨棄
    • 網路介面\封包輸出錯誤
    • 網路介面\位元組總計/秒
    • 網路介面\目前的带寬

步驟 4：針對 SQL Server 中的高 CPU 使用量進行疑難解答

如果在系統上執行 CPU 密集型查詢，可能會導致其他查詢耗盡 CPU 容量。 不過，更頻繁地，來自查詢的高CPU使用量可能表示需要優化查詢。 請遵循下列步驟來針對問題進行疑難解答：

  1. 首先，找出 SQL Server 是否導致高 CPU 使用量（使用 Perfmon 計數器）。
  2. 識別導致 CPU 使用量的查詢。
  3. 更新統計數據。
  4. 新增遺漏的索引。
  5. 調查並解決參數敏感性問題。
  6. 調查並解決 SARGability 問題。
  7. 停用繁重的追蹤。
  8. 修正 SOS_CACHESTORE 線程同步鎖定爭用。
  9. 設定虛擬機。
  10. 藉由新增更多 CPU 來相應增加系統。

如需詳細的疑難解答步驟，請參閱 針對 SQL Server 中的高 CPU 使用量問題進行疑難解答。

步驟 5：針對造成 SQL Server 緩慢的過多 I/O 進行疑難解答

SQL Server 工作負載整體速度緩慢的另一個常見原因是 I/O 問題。 I/O 速度緩慢可能會影響系統上大部分或所有查詢。 使用下列方法來針對問題進行疑難解答：

  • 檢查硬體問題：

    • SAN 設定錯誤（交換器、纜線、HBA、記憶體）。
    • 超過 I/O 容量（整個 SAN 網路不平衡，不只是後端記憶體，請檢查所有共用 SAN 的伺服器 I/O 輸送量）。
    • 驅動程式或韌體問題或更新。

  • 檢查造成大量 I/O 和飽和磁碟磁碟區且具有 I/O 要求的次佳 SQL Server 查詢。

    • 尋找造成大量邏輯讀取（或寫入）的查詢，並微調這些查詢，以使用適當的索引將磁碟 I/O 最小化是第一個步驟。
    • 讓統計數據保持更新，因為它們提供查詢優化器有足夠的資訊來選擇最佳計劃。
    • 重新設計查詢，有時數據表可能有助於改善 I/O。

  • 篩選驅動程式：如果文件系統篩選驅動程序處理大量 I/O 流量，SQL Server I/O 回應可能會受到嚴重影響。

    • 從防毒掃描中排除資料資料夾，並讓軟體廠商更正篩選驅動程序問題，以防止對I/O效能造成影響。

  • 其他應用程式：SQL Server 相同電腦上的另一個應用程式可能會讓 I/O 路徑飽和，並出現過多的讀取或寫入要求。 這種情況可能會將 I/O 子系統推送到容量限制之外，並導致 SQL Server 的 I/O 速度變慢。 識別應用程式並微調應用程式，或將其移至別處以消除其在 I/O 堆疊上的影響。 此問題也可能是因為在其他電腦上執行的應用程式，但與這個SQL Server 計算機共用相同的SAN所造成。 請與您的 SAN 系統管理員合作，以平衡 I/O 流量（請參閱 檢查硬體問題）。

如需 SQL Server I/O 相關問題的詳細疑難解答，請參閱 針對 I/O 問題所造成的 SQL Server 效能緩慢進行疑難解答。

步驟 6：針對記憶體問題進行疑難解答

整體或 SQL Server 內部的記憶體不足可能會導致查詢等候記憶體授與 （） 或編譯記憶體時RESOURCE_SEMAPHORERESOURCE_SEMAPHORE_QUERY_COMPILE速度緩慢。 使用下列方法來針對問題進行疑難解答：

  • 使用 Perfmon 計數器檢查作業系統層級的外部記憶體：

    • Memory\Available MBytes
    • Process^\Working Set （所有實例）
    • Process!!\Private Bytes （所有實例）

  • 針對內部記憶體壓力，請使用 SQL Server 查詢來查詢sys.dm_os_memory_clerks或使用 DBCC MEMORYSTATUS。

  • 檢查 SQL Server 錯誤記錄檔是否有 701 錯誤。

如需詳細的疑難解答步驟，請參閱 針對 SQL Server 中的記憶體不足或記憶體不足問題進行疑難解答。

步驟 7：針對封鎖問題進行疑難解答

鎖定擷取是用來保護資料庫系統中的資源。 如果取得鎖定很長一段時間，而其他會話最終會等候這些鎖定，您就會遇到封鎖案例。

SQL Server 等資料庫系統上會發生短暫的封鎖。 但長時間封鎖，特別是當大部分或所有查詢都在等待鎖定時，可能會導致整個伺服器被視為沒有回應。

使用下列步驟來針對問題進行疑難解答：

  1. 查看 DMV 輸出 sys.dm_exec_requests中的數據行或BlkBy預存程式輸出中的數據sp_who2行，以blocking_session_id識別前端封鎖會話。

  2. 尋找頭部封鎖鏈結執行的查詢（長時間保留鎖定的內容）。

    如果前端封鎖會話上沒有主動執行的查詢，可能會因為應用程式問題而造成孤立的交易。

  3. 重新設計或調整前端封鎖查詢以更快執行，或減少交易內的查詢數目。

  4. 檢查查詢中使用的交易隔離並調整。

如需封鎖案例的詳細疑難解答，請參閱 瞭解並解決 SQL Server 封鎖問題。

步驟 8：針對排程器問題進行疑難解答（非產生、死鎖排程器、非產生 IOCP 接聽程式、資源監視器）

SQL Server 會使用合作式排程機制（排程器）將其線程公開給操作系統，以在 CPU 上進行排程。 如果 SQL 排程器有問題，SQL Server 線程可能會停止處理查詢、登入、註銷等等。 因此，根據排程器的影響，SQL Server 似乎沒有回應，部分或完全。 排程器問題可能會導致各種問題，包括產品錯誤、外部和篩選驅動程式，以及硬體問題。

請遵循下列步驟來針對這些問題進行疑難解答：

  1. 檢查您的 SQL Server 錯誤記錄檔中是否有下列錯誤，因為回報的 SQL Server 回應不足：

    • ***********************************************
*
* BEGIN STACK DUMP:
* 03/10/22 21:16:35 spid 22548
*
* Non-yielding Scheduler
*
***********************************************

    • **********************************************
*
* BEGIN STACK DUMP:
* 03/25/22 08:50:29 spid 355
*
* Deadlocked Schedulers
*
* ********************************************


    • * *******************************************************************************                                
*                                                                                                                
* BEGIN STACK DUMP:                                                                                              
* 09/07/22 23:01:04 spid 0                                                                                     
*                                                                                                                
* Non-yielding IOCP Listener                                                                                     
*                                                                                                                
* *******************************************************************************   

    • * ********************************************
*
* BEGIN STACK DUMP:
* 07/25/22 11:44:21 spid 2013
*
* Non-yielding Resource Monitor
*
* ********************************************

  2. 如果您找到其中一個錯誤，請識別您使用的 SQL Server 累積更新 （CU） 版本。 檢查您的目前 CU 之後，CU 是否有任何固定的問題。 如需 SQL Server 修正，請參閱 目前支援的 SQL Server 版本可用的最新更新。 如需詳細的修正清單，您可以下載此 Excel 檔案。

  3. 如需更多想法，請使用 針對 SQL Server 排程和產生 進行疑難解答。

  4. 檢查可能導致死結排程器的大量封鎖案例或大量平行處理原則查詢。 如需詳細資訊，請參閱 死結排程器的陶。

  5. 若為非產生 IOCP 接聽程式，請檢查您的系統是否記憶體不足，且 SQL Server 正在分頁。另一個原因可能是防病毒軟體或入侵預防軟體攔截 I/O API 呼叫，並降低線程活動的速度。 如需詳細資訊，請參閱 IOCP接聽程式是否實際接聽？ 以及 載入特定模組或篩選驅動程式時的效能和一致性問題。

  6. 針對資源監視器問題，在某些情況下，您可能不一定關心這個問題。 如需詳細資訊，請參閱 資源監視器在執行 SQL Server 的伺服器上輸入非產生條件。

  7. 如果這些資源沒有説明，請藉由上傳記憶體轉儲進行分析，找出在 \LOG 子目錄中建立的記憶體轉儲，並使用 Microsoft CSS 開啟支援票證。

步驟 9：尋找需要大量資源的分析工具或 XEvent 追蹤

尋找作用中的擴充事件或 SQL Server Profiler 追蹤，特別是那些篩選文字數據行（資料庫名稱、登入名稱、查詢文字等等） 的人員。 可能的話，請停用追蹤，並查看查詢效能是否改善。 根據選取的事件，每個線程可能會耗用額外的CPU，而導致整體速度變慢。 若要識別擴充事件的作用中追蹤，請參閱 sys.dm_xe_sessions 和 Profiler 追蹤，請參閱 sys.traces。

SELECT * FROM sys.dm_xe_sessions
GO
SELECT * FROM sys.traces
  • Last updated on