MSSQLSERVER_833

適用於：SQL Server Azure SQL 受控執行個體

詳細資料

屬性	值
產品名稱	SQL Server
事件識別碼	833
事件來源	MSSQLSERVER
元件	SQLEngine
符號名稱	BUF_LONG_IO
訊息文字	在資料庫中 [%ls] (%d)的檔案 [%ls] 上，SQL Server 發現 I/O 要求的 %d 發生時間超過 %d 秒才能完成。 作業系統檔案控制代碼為 0x%p。 最新長 I/O 的位移為： %#016I64x。

說明

此訊息表示 SQL Server 已經從磁碟發出讀取或寫入要求，且該要求花費超過 15 秒才傳回。 SQL Server 會報告此錯誤，並指出 I/O 子系統發生問題。 資料庫管理系統 （DBMS），例如 SQL Server，依賴檔案輸入和輸出 （I/O） 作業的時間軸。 下列任何一個專案都可能導致停滯或停滯的 I/O 作業，並對 SQL Server 回應性和效能造成負面影響：

• 故障的硬體
• 未正確設定的硬體
• 韌體設定
• 篩選驅動程式
• 壓縮
• Bug
• I/O 路徑中的其他條件

這些 I/O 問題可能會導致下列行為發生：

• 阻塞。
• 閂鎖爭用和逾時。
• 回應時間變慢。
• 資源界限的延展。
• 您也可以注意到與此訊息相關聯的其他徵兆，例如：
  • PAGEIOLATCH 等候時間很高。
  • 系統事件記錄檔中的警告或錯誤。
  • 系統監視器計數器中磁碟延遲問題的指示。

當 I/O 作業擱置 15 秒或更長時間時，SQL Server 會執行下列步驟：

1. 偵測作業已擱置中。

2. 將參考訊息寫入 SQL Server 錯誤記錄檔，如詳細數據一節中所述。

   下表提供此參考訊息不同區段的說明：

訊息文字	描述
<發生次數> （秒）	在 15 秒內未完成讀取或寫入作業的 I/O 要求數目。
檔案資訊	完整檔名、資料庫名稱和資料庫識別 （DBID） 編號。
Handle	檔案的操作系統句柄。 您可以使用操作系統句柄搭配調試程式或其他公用程式，協助追蹤 I/O 要求封包 （IRP） 要求。
Offset	上次停滯 I/O 作業或最後一次停滯 I/O 作業的位移。 您可以使用位移搭配調試程式或其他公用程式來協助追蹤 IRP 要求。 注意： 當參考訊息寫入 SQL Server 錯誤記錄檔時，I/O 作業可能不再停滯或停滯。

可能的原因

參考訊息表示目前的負載可能遇到下列其中一個情況：

• 工作負載超過 I/O 路徑功能，可能是因為 I/O 子系統設定錯誤（SAN、NAS 和直接連結），或因為已達到硬體容量。
• 工作負載超過目前的系統功能，例如 I/O、CPU 和 HBA。
• I/O 路徑有故障的軟體。 可能是韌體或驅動程序問題。
• I/O 路徑有硬體元件故障。
• 操作系統層級的效能問題。
• 篩選驅動程式介入資料庫檔案的 I/O 進程或儲存路徑。 例如，防毒程式。

SQL Server 會記錄起始 I/O 要求的時間，並記錄 I/O 完成的時間。 如果差異為 15 秒或更長，則會偵測到此狀況。 這也表示 SQL Server 不是此訊息所描述和報告延遲 I/O 條件的原因。 此條件稱為「停止 I/O」。 大部分的磁碟要求都會以磁碟的典型速度發生。 此一般磁碟速度通常稱為磁碟搜尋時間。 大部分標準磁碟的磁碟搜尋時間會在 10 毫秒以下發生。 因此，15 秒的時間很長，系統 I/O 路徑會返回 SQL Server。 如需詳細資訊，請參閱 詳細資訊 一節。

使用者動作

執行下列步驟來針對此錯誤進行疑難解答：

1. 檢查系統事件記錄檔中的硬體相關錯誤訊息。
2. 檢查硬體特定記錄是否可用。 使用必要的方法和技術來判斷操作系統、驅動程式或 I/O 硬體延遲的原因。
3. 更新所有設備驅動器和韌體，或執行與您的 I/O 子系統相關聯的其他診斷。
4. 篩選驅動程式可能會讓磁碟存取變慢，例如防病毒軟體程式。 若要提高存取速度，請從使用中病毒掃描的錯誤訊息中排除指定的 SQL Server 資料檔。 如需詳細資訊，請參閱如何選擇要在執行 SQL Server 的電腦上執行的防病毒軟體（microsoft.com）。
   • 使用 fltmc.exe 命令行公用程式來查詢系統上安裝的所有篩選驅動程式，並瞭解它在資料庫檔案記憶體路徑上執行的函式。
5. 使用 效能監視器 來檢查下列計數器：
   • 平均磁碟秒/傳輸
   • 平均磁碟佇列長度
   • 目前的磁碟佇列長度
6. 您也可以使用 Storport ETW 記錄等設施來測量對磁碟單位提出的要求延遲。 另一個類似的磁碟 I/O 疑難解答套件可作為 Windows Performance Recorder 的內建配置檔。
7. 監視 sys.dm_io_virtual_file_stats ，併為記憶體輸送量選擇適當的儲存層和IOPS。

如需診斷和疑難解答因 I/O 問題而發生的 SQL Server 效能問題的引導式逐步解說，請參閱 針對 I/O 問題所造成的 SQL Server 效能緩慢進行疑難解答。

其他相關資訊

停滯的 I/O 和停滯的 I/O

停滯的 I/O

停滯的 I/O 定義為未完成的 I/O 要求。 經常，停滯的 I/O 表示停滯的 IRP。 若要解決停滯的 I/O 條件，您通常必須重新啟動電腦或執行類似的動作。 停滯的 I/O 條件通常表示下列其中一個問題：

• 硬體故障。
• I/O 路徑元件中的 Bug。

停滯的 I/O

停滯的 I/O 定義為已完成的 I/O 要求，或需要花費太多時間才能完成。 由於下列其中一個原因，通常會發生停滯的 I/O 行為：

• 硬體組態。
• 韌體設定。
• 需要硬體或軟體廠商協助以追蹤和解決的篩選條件驅動程序問題。

SQL Server 停止 I/O 並停滯的 I/O 記錄和報告

SQL Server 支援每年會處理許多涉及停滯或停滯 I/O 問題的案例。 這些 I/O 問題會以不同的方式出現。 I/O 問題是一些最難以診斷和偵錯的問題，而且需要大量時間和資源，才能從Microsoft和客戶進行偵錯。 I/O 要求的報告和記錄是以每個檔案為基礎所設計。 偵測和報告停滯和停滯的 I/O 要求是兩個不同的動作。

錄音

SQL Server 中發生記錄動作時有兩個時間。 第一個是 I/O 作業完成時。 第二個時刻是延遲寫入器執行的時間。 當延遲寫入器執行時，它會檢查所有暫止的數據和擱置的記錄檔 I/O 要求。 如果 I/O 要求超過 15 秒閾值，就會發生記錄作業。

報表

報告會以五分鐘以上的間隔發生。 在檔案上提出下一個 I/O 要求時，就會發生報告。 如果記錄動作已發生，且自上次報告發生后已經過五分鐘以上，則會將詳細數據區段中提及的資訊訊息寫入 SQL Server 錯誤記錄檔。

15 秒的閾值無法調整。 不過，您可以使用追蹤旗標 830 來停用停滯或停滯的 I/O 偵測，但不建議這麼做。

您可以使用追蹤旗標 830 來停用停滯和停滯 I/O 的偵測。 若要在每次啟動 SQL Server 時啟用此旗標，請使用 -T830 啟動參數。 若要停用目前正在執行的 SQL Server 實例偵測，請使用下列語句：

    dbcc traceon(830, -1)

此設定僅適用於 SQL Server 進程的存限。

注意

只會報告一次變成停滯或停滯的 I/O 要求。 例如，如果訊息報告 10 個 I/O 要求已停止，這些 10 份報告將不會再次發生。 如果下一則訊息回報 15 個 I/O 要求已停止，表示 15 個新的 I/O 要求已停止。

追蹤 I/O 要求封包 （IRP）

SQL Server 會使用標準Microsoft Windows API 呼叫來讀取和寫入數據。 例如，SQL Server 會使用下列函式：

• WriteFile
• ReadFile
• WriteFileScatter
• ReadFileGather

讀取或寫入要求是由 Windows 處理為 I/O 要求封包（IRP）。 若要判斷 IRP 的狀態，請使用下列兩項功能：

• Windows 支援
• Storport ETW 記錄

建議您檢查下列專案是否有任何可用的更新：

• The BIOS
• 韌體
• 任何其他 I/O 路徑元件

請連絡硬體廠商，再執行其他偵錯動作。 偵錯會話可能會涉及第三方驅動程式、韌體或篩選驅動程式元件。

系統效能和查詢計劃動作

整體來說，系統效能在 I/O 處理中扮演重要角色。 在調查停滯或停滯 I/O 作業的報告時，您應該考慮系統的一般健康情況。 過多的負載可能會導致整體系統變慢，包括 I/O 處理。 發生問題時系統的行為可能是判斷問題根本原因的一個關鍵因素。 例如，如果 CPU 使用量在發生問題時增加或維持高，則可能表示系統進程使用太多 CPU 而其他進程受到負面影響。

效能計數器

若要監視 I/O 效能，請檢查下列性能計數器，以取得特定 I/O 路徑資訊：

• 平均磁碟秒/傳輸
• 平均磁碟佇列長度
• 目前的磁碟佇列長度

例如，執行 SQL Server 之電腦上的平均磁碟秒/傳輸時間通常小於 15 毫秒。 如果 Average Disk Sec/Transfer 值攀升，表示 I/O 子系統無法與 I/O 需求保持最佳狀態。

使用性能計數器時請小心，因為 SQL Server 充分利用大量推送磁碟佇列長度的異步 I/O 功能。 因此，單獨使用較長的磁碟佇列長度不會指出問題。

在 Windows 系統監視器中，您可以檢閱每個受影響磁碟的計數器「實體磁碟：磁碟位元組/秒」，並將活動速率與每個進程的計數器「進程：IO 數據位元組/秒」和「行程：IO 其他位元組/秒」進行比較。 您可以這麼做來識別特定進程集是否產生過多的 I/O 要求。 Process 物件中的其他各種 I/O 相關計數器會顯示更細微的資訊。 如果您判斷 SQL Server 實例負責伺服器上過多的 I/O 負載，請參閱索引和平行處理原則的下一節。 如需偵測和解決 I/O 瓶頸的詳細討論，請參閱 針對 I/O 問題所造成的 SQL Server 效能緩慢進行疑難解答。

索引和平行處理原則

經常發生 I/O 高載，因為遺漏索引。 此行為可能會嚴重推送 I/O 路徑。 使用索引轉彎精靈 （ITW） 的傳遞可能有助於解決系統上的 I/O 壓力。 如果查詢受益於索引而非數據表掃描，或可能是它使用排序或哈希，則系統可能會獲得下列優點：

• 實體 I/O 中會縮減，以完成直接為查詢建立效能優勢的動作。
• 必須翻轉數據快取中的頁面較少。 因此，數據快取中的頁面仍與作用中查詢相關。
• 因為索引可能遺失或統計數據過期，因此會使用排序和哈希。 您可以藉由新增一或多個索引來減少 tempdb 的使用和爭用。
• 資源、平行作業或兩者都會減少。 因為 SQL Server 不保證平行查詢執行，而且系統會考慮系統上的負載，因此最好將所有查詢優化以進行序列執行。 若要優化查詢，請開啟 [查詢分析器]，並將 [平行處理原則的最大程度] 選項sp_configure值設定為 1。 如果所有查詢都會微調為以序列作業的方式立即執行，則平行執行通常只是更好的結果。 不過，通常會選取平行執行，因為數據量很大。 對於遺漏的索引，可能必須進行大型排序。 執行排序作業的多個背景工作角色將會建立更快的回應。 不過，此動作可能會大幅增加系統的壓力。 許多背景工作角色的大型讀取要求可能會造成 I/O 高載，並增加 CPU 使用量。 如果新增索引，或發生另一個微調動作，查詢通常可以微調以更快執行，並使用較少的資源。

SQL Server 支援的實際範例

SQL Server 支援和 Windows 呈報支援已處理下列範例。 這些範例旨在提供參考框架，並協助您設定有關停滯和停滯 I/O 情況的期望。 它們也會提供一個架構，讓您了解系統可能受到影響或回應的方式。 沒有特定的硬體或一組驅動程式造成任何特定風險，或對另一個硬體造成風險增加。 在這方面，所有系統都相同。

範例 1：停滯 45 秒的記錄寫入

嘗試寫入 SQL Server 記錄檔會定期停滯約 45 秒。 記錄寫入不會及時完成。 此行為會建立造成 30 秒用戶端逾時的封鎖條件。

應用程式已將認可提交至 SQL Server，而認可會卡在記錄寫入擱置中。 此行為會導致查詢繼續保留鎖定，並封鎖來自其他用戶端的連入要求。 然後，其他用戶端會開始逾時。這加劇了問題，因為應用程式不會在發生查詢逾時時回復開啟的交易。 這會建立數百個持有鎖定的開啟交易。 因此，會發生嚴重的封鎖情況。

如需交易處理和封鎖的詳細資訊，請參閱下列Microsoft知識庫文章： 224453瞭解並解決 SQL Server 封鎖問題

應用程式會使用連線共用來服務網站。 隨著更多連線遭到封鎖，網站會建立更多連線。 這些聯機會遭到封鎖，迴圈會繼續。

記錄寫入大約需要 45 秒才能完成。 不過，此時會備份數百個連線。 封鎖問題會導致 SQL Server 和應用程式有幾分鐘的復原時間。 結合應用程式問題，停滯的 I/O 條件會對系統產生非常負面影響。

解決方法

問題會追蹤到主機總線配接器 （HBA） 驅動程式中的卡住 I/O 要求。 計算機有多個具有故障轉移支援的 HBA 卡。 當一個 HBA 落後或未與儲存局域網路 （SAN） 通訊時，會將「故障轉移前重試」逾時值設定為 45 秒。 逾時超過時，I/O 要求會路由傳送至第二個 HBA。 第二個 HBA 會處理要求並快速完成。 為了協助防止這類停滯狀況，硬體製造商建議在故障轉移前重試五秒的設定。

範例 2：篩選驅動程式介入

許多防病毒軟體程式和備份產品都使用 I/O 篩選器驅動程式。 這些 I/O 篩選驅動程式會成為 I/O 要求堆疊的一部分，並可存取 IRP 要求。 Microsoft產品支援服務已看到錯誤的各種問題，這些錯誤會在篩選驅動程式實作中建立停滯的 I/O 條件或停滯的 I/O 條件。

其中一種情況是備份處理的篩選驅動程式，允許備份發生備份時開啟的檔案備份。 系統管理員已在檔案備份選取範圍中包含 SQL Server 資料檔案目錄。 備份發生時，備份會嘗試在備份啟動時收集檔案的正確映像。 這樣做會延遲 I/O 要求。 當軟體處理它們時，I/O 要求一次只能完成一個。

當備份啟動時，SQL Server 效能會大幅下降，因為 SQL Server 的 I/O 會強制一次完成一個。 一次一個邏輯會讓 I/O 作業無法以異步方式執行，這加劇了問題。 因此，當 SQL Server 預期要張貼 I/O 要求並繼續時，背景工作角色會卡在讀取或寫入呼叫中，直到 I/O 要求完成為止。 篩選驅動程序的動作可有效地停用 SQL Server 讀取等處理工作。 此外，篩選驅動程式中的另一個 Bug 會在程式中一次離開該錯誤，即使備份完成也一次。 還原 SQL Server 效能的唯一方法是重新啟動 SQL Server，以便釋放並重新取得檔句柄，而不需要篩選驅動程序互動。

解決方法

若要解決此問題，SQL Server 數據檔會從文件備份程式中移除。 軟體製造商已修正讓檔案處於「一次一個」模式的問題。

範例 3：隱藏的錯誤

許多高階系統都有多重通道 I/O 路徑，可處理負載平衡或類似的活動。 Microsoft產品支持發現負載平衡軟體發生問題，其中 I/O 要求失敗，但軟體無法正確處理錯誤狀況。 軟體可以嘗試無限次重試。 I/O 作業停滯，且 SQL Server 無法完成指定的動作。 與稍早所述的記錄寫入條件類似，許多不良的系統行為可能會發生於這類狀況對系統進行楔形處理之後。

解決方法

若要解決此問題，請重新啟動 SQL Server。 不過，有時候您需要重新啟動操作系統以還原處理。 我們也建議您從 I/O 廠商取得軟體更新。

範例 4：遠端記憶體、鏡像和 RAID 磁碟驅動器

許多系統都使用鏡像或採用類似的步驟來防止數據遺失。 某些使用鏡像的系統是以軟體為基礎，有些則以硬體為基礎。 這些系統的 Microsoft 支援服務 通常會發現的情況會增加延遲。

當 I/O 在視為完成之前必須完成時，就會在整體 I/O 時間增加。 針對遠端鏡像安裝，可能會涉及網路重試。 發生磁碟驅動器失敗，並重建RAID系統時，I/O 模式也可以中斷。

解決方法

需要嚴格的組態設定，以減少鏡像或突襲重建作業的延遲。

範例 5：壓縮

Microsoft不支援壓縮磁碟驅動器上的 SQL Server 數據檔和記錄檔。 NTFS 壓縮對 SQL Server 而言並不安全，因為NTFS壓縮會中斷寫入預先記錄 （WAL） 通訊協定。 NTFS 壓縮也需要針對每個 I/O 作業增加處理。 壓縮會建立「一次一個」之類的行為，導致發生嚴重的效能問題。

解決方法

若要解決此問題，請取消壓縮數據和記錄檔。

如需詳細資訊，請參閱 支援壓縮磁碟區上的資料庫。

其他資料點

PAGEIOLATCH_* 和寫入記錄等候sys.dm_os_wait_stats動態管理檢視 （DMV） 是調查 I/O 路徑效能的關鍵指標。 如果看到大量的 PAGEIOLATCH 等候，即表示 SQL Server 正在等候 I/O 子系統。 一定數量的PAGEIOLATCH等候是一般且預期的行為。 不過，如果平均PAGEIOLATCH等候時間一直大於10毫秒，您應該調查 I/O 子系統承受壓力的原因。 如需詳細資訊，請參閱下列文件：

• 針對 I/O 所造成 SQL Server 效能緩慢的問題進行疑難排解
• sys.dm_os_waiting_tasks （Transact-SQL）
• sys.dm_exec_requests
• SQL Server 等候類型存放庫

參考

• 使用 DISKSPD 來測試工作負載儲存效能
• 826433新增 SQL Server 診斷，以偵測因讀取過時或寫入遺失而未報告的 I/O 問題
• 記錄和數據儲存演算法

SQL Server 要求系統支援「保證傳遞至穩定媒體」，如 SQL Server I/O 可靠性計劃需求中所述。 如需 SQL Server 資料庫引擎輸入和輸出需求的詳細資訊，請流覽 資料庫引擎 輸入/輸出需求。

如需有關 I/O 錯誤的詳細資訊，請參閱 Microsoft SQL Server I/O 基本概念，第 2 章。