最近遇到一個(gè)SQL Server服務(wù)器響應(yīng)極度緩慢，并且出現(xiàn)客戶(hù)端請(qǐng)求報(bào)錯(cuò)的情況，在數(shù)據(jù)庫(kù)中的errorlog中出現(xiàn)磁盤(pán)請(qǐng)求超過(guò)15s才完成的error消息。

對(duì)于此類(lèi)問(wèn)題，到底是存儲(chǔ)系統(tǒng)或者磁盤(pán)的故障，還是SQL Server 自己的問(wèn)題，亦或是應(yīng)用程序引發(fā)的呢？又要如何解決？

本文將對(duì)引起此問(wèn)題的某一方面的因素進(jìn)行簡(jiǎn)單的分析，但是無(wú)法涵蓋所有潛在的可能性，因此遇到類(lèi)似問(wèn)題還要做具體的分析。

SQL Server中的磁盤(pán)請(qǐng)求超時(shí)

　　該錯(cuò)誤的英文版的錯(cuò)誤信息如下:

　　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

　　中文版的錯(cuò)誤信息如下

　　SQL Server 已遇到 %1! 次對(duì)數(shù)據(jù)庫(kù) ID %4! 中的文件 [%3!] 進(jìn)行的 I/O 請(qǐng)求超過(guò) %2! 秒才完成。操作系統(tǒng)文件句柄為 0x%5!。最新的長(zhǎng)時(shí)間 I/O 的偏移量為: %6!

　　參考message信息中的833號(hào)錯(cuò)誤消息

具體的833 error 申請(qǐng)磁盤(pán)請(qǐng)求超時(shí)現(xiàn)象

　　具體報(bào)錯(cuò)情況如下：

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

　　也就是說(shuō)在數(shù)據(jù)庫(kù)的文件自動(dòng)增長(zhǎng)的過(guò)程中遇到了錯(cuò)誤。

。

　　比較有意思的是某DBA將此錯(cuò)誤信息報(bào)告給負(fù)責(zé)存儲(chǔ)（SAN存儲(chǔ)，并非掛的磁盤(pán)）的工程師，認(rèn)為是可能存儲(chǔ)系統(tǒng)存在故障或者不穩(wěn)定造成的，

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

　　因?yàn)閿?shù)據(jù)庫(kù)服務(wù)器使用的存儲(chǔ)是高性能的SAN存儲(chǔ)，存儲(chǔ)是作為一個(gè)服務(wù)存在的，有N多服務(wù)器共同來(lái)使用的，其他服務(wù)器并沒(méi)有出現(xiàn)磁盤(pán)請(qǐng)求，不太可能說(shuō)某一臺(tái)服務(wù)器會(huì)出現(xiàn)疑似“存儲(chǔ)故障”就簡(jiǎn)單認(rèn)定為是存儲(chǔ)故障。

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

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

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

　　總之，意思就是，SQL Server在請(qǐng)求磁盤(pán)讀寫(xiě)的時(shí)候，遇到磁盤(pán)繁忙或者其他一些因素，超過(guò)了15秒還沒(méi)有完成
　　比如數(shù)據(jù)的讀寫(xiě)的時(shí)候需要向磁盤(pán)發(fā)起請(qǐng)求，而磁盤(pán)正忙或者其他問(wèn)題，來(lái)不及或者相應(yīng)的不夠及時(shí)，這樣無(wú)疑會(huì)嚴(yán)重影響SQL Server對(duì)外提供服務(wù)器的響應(yīng)時(shí)間。

　　上面簡(jiǎn)單分析了，因?yàn)樵搯?wèn)題并非普片發(fā)生的，存儲(chǔ)系統(tǒng)不太可能出現(xiàn)問(wèn)題，那就很有可能定位到當(dāng)前服務(wù)器自身的因素了。

原因分析

　　因?yàn)槭菍?zhuān)門(mén)的SQL Server服務(wù)器，沒(méi)有其他應(yīng)用程序的請(qǐng)求，很有可能跟向sqlserver數(shù)據(jù)庫(kù)發(fā)起的請(qǐng)求有關(guān)。

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

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

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

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

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

　　因?yàn)轭?lèi)似查詢(xún)還是執(zhí)行的比較頻繁的，此類(lèi)Session會(huì)從不同的客戶(hù)端發(fā)起，一旦SQL的執(zhí)行效率降下來(lái)，服務(wù)器上會(huì)積壓大量的活動(dòng)Session

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

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

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

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

　　由此也不難理解，數(shù)十個(gè)查詢(xún)的Session正在以一種不合理的方式瘋狂地想磁盤(pán)發(fā)出請(qǐng)求，磁盤(pán)正在忙于活動(dòng)Session的數(shù)據(jù)請(qǐng)求，出現(xiàn)無(wú)法響應(yīng)因?yàn)閿?shù)據(jù)或者索引文件的自動(dòng)增長(zhǎng)請(qǐng)求，造成一開(kāi)始說(shuō)的問(wèn)題。

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

總結(jié)：

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