共計 2445 個字符，預計需要花費 7 分鐘才能閱讀完成。
今天就跟大家聊聊有關 SQL Server 磁盤請求超時的 833 錯誤原因及解決方法，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
最近遇到一個 SQL Server 服務器響應極度緩慢，并且出現客戶端請求報錯的情況，在數據庫中的 errorlog 中出現磁盤請求超過 15s 才完成的 error 消息。
對于此類問題，到底是存儲系統或者磁盤的故障，還是 SQL Server 自己的問題，亦或是應用程序引發的呢？又要如何解決？
SQL Server 中的磁盤請求超時
該錯誤的英文版的錯誤信息如下:
SQL Server has encountered %d occurrence(s) of I/O requests taking longer than %d seconds to complete on file [%ls] in database id %d. The OS file handle is 0x%p. 0 The offset of the latest long I/O is: %#016I64x
中文版的錯誤信息如下
SQL Server 已遇到 %1! 次對數據庫 ID %4! 中的文件 [%3!] 進行的 I/O 請求超過 %2! 秒才完成。操作系統文件句柄為 0x%5!。最新的長時間 I/O 的偏移量為: %6!
參考 message 信息中的 833 號錯誤消息
具體的 833 error 申請磁盤請求超時現象
具體報錯情況如下：
SQL Server 已遇到 m 次對數據庫 n 中的文件 *** 進行的 I/O 請求超過 15 秒才完成。操作系統文件句柄為 ***。最新的長時間 I/O 的偏移量為: ***
也就是說在數據庫的文件自動增長的過程中遇到了錯誤。
。
比較有意思的是某 DBA 將此錯誤信息報告給負責存儲（SAN 存儲，并非掛的磁盤）的工程師，認為是可能存儲系統存在故障或者不穩定造成的，
存儲工程師認為存儲沒有問題，檢查服務器后說服務器不正常，內存“幾乎占滿”，對于數據庫服務器，內存“幾乎占滿”的情況可以說是完全正常的，鑒于負責存儲的工程師并非專業 DBA，對于 SQL Server 數據庫服務器的內存使用可能不是太了解，提出此疑問也可以理解。
因為數據庫服務器使用的存儲是高性能的 SAN 存儲，存儲是作為一個服務存在的，有 N 多服務器共同來使用的，其他服務器并沒有出現磁盤請求，不太可能說某一臺服務器會出現疑似“存儲故障”就簡單認定為是存儲故障。
那么究竟原因在什么地方呢？
數據庫引擎錯誤 833 的含義
首先來看這個 833 錯誤的具體含義是什么，就不自己裝 13 解釋一通了，那本經典的書上寫的很清楚了。
總之，意思就是，SQL Server 在請求磁盤讀寫的時候，遇到磁盤繁忙或者其他一些因素，超過了 15 秒還沒有完成 比如數據的讀寫的時候需要向磁盤發起請求，而磁盤正忙或者其他問題，來不及或者相應的不夠及時，這樣無疑會嚴重影響 SQL Server 對外提供服務器的響應時間。
上面簡單分析了，因為該問題并非普片發生的，存儲系統不太可能出現問題，那就很有可能定位到當前服務器自身的因素了。
原因分析
因為是專門的 SQL Server 服務器，沒有其他應用程序的請求，很有可能跟向 sqlserver 數據庫發起的請求有關。
其實發生這個問題之前，早就有預兆了，平時還算穩定的服務器（CPU 很少超過 60%，內存的 PLE 也可以穩定在 20 分鐘以上，磁盤 IO 延遲較低等等），只是偶爾會存在抽風一陣子的情況
抽風的時候表現為 CPU 狂飆到 80% 左右，內存的 PLE 會嚴重下降，IO 延遲嚴重增高。
現在只能從 SQL Server 的 Session 入手，在觀察 SQL Server 中的活動 Session 的時候，發現某一類的 SQL 語句的查詢時間非常長，平時這類 SQL 在某一個時間段內執行的頻率還算比較高。
但是正常情況下，這類 SQL 的執行效率還是比較高的，為什么突然就變的非常之底？
在檢查活動 Session 的對應的執行計劃的時候，發現這類活動 Session 的等待狀態都是 IO 等待（PAGEIOLATCH_SH），同時 SQL 的執行完全是意料之外的執行方式。
因為類似查詢還是執行的比較頻繁的，此類 Session 會從不同的客戶端發起，一旦 SQL 的執行效率降下來，服務器上會積壓大量的活動 Session
為什么平時執行的好好的 SQL 語句突然就變的很慢很慢，
原因就在于在某一點，SQL Server 自動觸發了統計信息的更新，但是這是一個比較大的表，但是默認統計信息更新的取樣比例是不夠的，如果取樣百分比不夠，這個統計信息完全是不可用的。
一旦自動收集統計信息完成之后，會根據當前收集到的統計信息，向之前的 SQL 語句發出一種它認為高效的方式（table scan 而不是 index seek），其實這種方式并非是合理的，由此引發對應的 SQL 利用一種并非合理的執行計劃來實現查詢，同時會引發 Session 的擁堵，客戶端發過來大量的 Session 同時在利用一種低效的方式緩慢執行。
所以 CPU 會飆升，IO 延遲增加，內存的 PLE 嚴重下降。
由此也不難理解，數十個查詢的 Session 正在以一種不合理的方式瘋狂地想磁盤發出請求，磁盤正在忙于活動 Session 的數據請求，出現無法響應因為數據或者索引文件的自動增長請求，造成一開始說的問題。
最后經過索引重建（促使統計信息更新，當然純粹的統計信息更新也可以）解決，長期預防的話，需要安排 job 人為地定義統計信息更新的閾值以及取樣百分比。
數據庫服務器上的問題，很多問題都是一個連鎖反應的過程，對應觀察到的一部分現象，很有可能并不是表面上的反應的那樣（磁盤請求超時，問題出在存儲上？）專業的位置上必須要有專業的素養，比如一開始 DBA 誤以為是存儲問題，存儲工程師認為服務器內存用滿了是不正常的等，其實都不是問題的根本原因所在。面對問題，要追本溯源，找出來最根本的原因，才是解決問題的關鍵。
看完上述內容，你們對 SQL Server 磁盤請求超時的 833 錯誤原因及解決方法有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
