今天就跟大家聊聊有關SQL Server 磁盤請求超時的833錯誤原因及解決方法，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)提供高防服務器、云服務器、香港服務器、溫江服務器租用等

最近遇到一個SQL Server服務器響應極度緩慢，并且出現(xiàn)客戶端請求報錯的情況，在數(shù)據(jù)庫中的errorlog中出現(xiàn)磁盤請求超過15s才完成的error消息。

對于此類問題，到底是存儲系統(tǒng)或者磁盤的故障，還是SQL Server 自己的問題，亦或是應用程序引發(fā)的呢？又要如何解決？

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! 次對數(shù)據(jù)庫 ID %4! 中的文件 [%3!] 進行的 I/O 請求超過 %2! 秒才完成。操作系統(tǒng)文件句柄為 0x%5!。新的長時間 I/O 的偏移量為: %6!

參考message信息中的833號錯誤消息

具體的833 error 申請磁盤請求超時現(xiàn)象

具體報錯情況如下：

SQL Server 已遇到 m 次對數(shù)據(jù)庫 n 中的文件***進行的 I/O 請求超過 15 秒才完成。操作系統(tǒng)文件句柄為 ***。新的長時間 I/O 的偏移量為: ***

也就是說在數(shù)據(jù)庫的文件自動增長的過程中遇到了錯誤。

。

比較有意思的是某DBA將此錯誤信息報告給負責存儲（SAN存儲，并非掛的磁盤）的工程師，認為是可能存儲系統(tǒng)存在故障或者不穩(wěn)定造成的，

存儲工程師認為存儲沒有問題，檢查服務器后說服務器不正常，內(nèi)存“幾乎占滿”，對于數(shù)據(jù)庫服務器，內(nèi)存“幾乎占滿”的情況可以說是完全正常的，鑒于負責存儲的工程師并非專業(yè)DBA，對于SQL Server數(shù)據(jù)庫服務器的內(nèi)存使用可能不是太了解，提出此疑問也可以理解。

因為數(shù)據(jù)庫服務器使用的存儲是高性能的SAN存儲，存儲是作為一個服務存在的，有N多服務器共同來使用的，其他服務器并沒有出現(xiàn)磁盤請求，不太可能說某一臺服務器會出現(xiàn)疑似“存儲故障”就簡單認定為是存儲故障。

那么究竟原因在什么地方呢？

數(shù)據(jù)庫引擎錯誤833的含義

首先來看這個833錯誤的具體含義是什么，就不自己裝13解釋一通了，那本經(jīng)典的書上寫的很清楚了。

總之，意思就是，SQL Server在請求磁盤讀寫的時候，遇到磁盤繁忙或者其他一些因素，超過了15秒還沒有完成　　比如數(shù)據(jù)的讀寫的時候需要向磁盤發(fā)起請求，而磁盤正忙或者其他問題，來不及或者相應的不夠及時，這樣無疑會嚴重影響SQL Server對外提供服務器的響應時間。

上面簡單分析了，因為該問題并非普片發(fā)生的，存儲系統(tǒng)不太可能出現(xiàn)問題，那就很有可能定位到當前服務器自身的因素了。

原因分析

因為是專門的SQL Server服務器，沒有其他應用程序的請求，很有可能跟向sqlserver數(shù)據(jù)庫發(fā)起的請求有關。

其實發(fā)生這個問題之前，早就有預兆了，平時還算穩(wěn)定的服務器（CPU很少超過60%，內(nèi)存的PLE也可以穩(wěn)定在20分鐘以上，磁盤IO延遲較低等等），只是偶爾會存在抽風一陣子的情況

抽風的時候表現(xiàn)為CPU狂飆到80%左右，內(nèi)存的PLE會嚴重下降，IO延遲嚴重增高。

現(xiàn)在只能從SQL Server的Session入手，在觀察SQL Server中的活動Session的時候，發(fā)現(xiàn)某一類的SQL語句的查詢時間非常長，　　平時這類SQL在某一個時間段內(nèi)執(zhí)行的頻率還算比較高。

但是正常情況下，這類SQL的執(zhí)行效率還是比較高的，為什么突然就變的非常之底？

在檢查活動Session的對應的執(zhí)行計劃的時候，發(fā)現(xiàn)這類活動Session的等待狀態(tài)都是IO等待（PAGEIOLATCH_SH），同時SQL的執(zhí)行完全是意料之外的執(zhí)行方式。

因為類似查詢還是執(zhí)行的比較頻繁的，此類Session會從不同的客戶端發(fā)起，一旦SQL的執(zhí)行效率降下來，服務器上會積壓大量的活動Session

為什么平時執(zhí)行的好好的SQL語句突然就變的很慢很慢，

原因就在于在某一點，SQL Server自動觸發(fā)了統(tǒng)計信息的更新，但是這是一個比較大的表，但是默認統(tǒng)計信息更新的取樣比例是不夠的，如果取樣百分比不夠，這個統(tǒng)計信息完全是不可用的。

一旦自動收集統(tǒng)計信息完成之后，會根據(jù)當前收集到的統(tǒng)計信息，向之前的SQL語句發(fā)出一種它認為高效的方式（table scan而不是index seek），其實這種方式并非是合理的，　　由此引發(fā)對應的SQL利用一種并非合理的執(zhí)行計劃來實現(xiàn)查詢，同時會引發(fā)Session的擁堵，客戶端發(fā)過來大量的Session同時在利用一種低效的方式緩慢執(zhí)行。

所以CPU會飆升，IO延遲增加，內(nèi)存的PLE嚴重下降。

由此也不難理解，數(shù)十個查詢的Session正在以一種不合理的方式瘋狂地想磁盤發(fā)出請求，磁盤正在忙于活動Session的數(shù)據(jù)請求，出現(xiàn)無法響應因為數(shù)據(jù)或者索引文件的自動增長請求，造成一開始說的問題。

最后經(jīng)過索引重建（促使統(tǒng)計信息更新，當然純粹的統(tǒng)計信息更新也可以）解決，長期預防的話，需要安排job人為地定義統(tǒng)計信息更新的閾值以及取樣百分比。

數(shù)據(jù)庫服務器上的問題，很多問題都是一個連鎖反應的過程，對應觀察到的一部分現(xiàn)象，很有可能并不是表面上的反應的那樣（磁盤請求超時，問題出在存儲上？）　　專業(yè)的位置上必須要有專業(yè)的素養(yǎng)，比如一開始DBA誤以為是存儲問題，存儲工程師認為服務器內(nèi)存用滿了是不正常的等，其實都不是問題的根本原因所在。　　面對問題，要追本溯源，找出來最根本的原因，才是解決問題的關鍵。

看完上述內(nèi)容，你們對SQL Server 磁盤請求超時的833錯誤原因及解決方法有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

網(wǎng)站名稱：SQLServer磁盤請求超時的833錯誤原因及解決方法-創(chuàng)新互聯(lián)
網(wǎng)址分享：http://aaarwkj.com/article42/gesec.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、微信小程序、App開發(fā)、外貿(mào)建站、企業(yè)網(wǎng)站制作、響應式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)