SQL Server 2000 SP4得問題的檢測與解決
以下的文章主要描述的是檢測與解決 SQL Server 2000 SP4中的一些問題，我們大家都知道像 SQL Server 這樣的數(shù)據(jù)庫管理系統(tǒng)，其主要是依賴于文件輸入與文件輸出操作的及時進行。在實際操作中有故障或配置不當。
硬件、固件設(shè)置、篩選器驅(qū)動程序、壓縮、程序錯誤以及 I/O 路徑內(nèi)的其他情況都可能導致阻塞或延遲 I/O 問題，并且很快對 SQL Server 性能產(chǎn)生消極影響。
上述問題對 SQL Server 的影響因問題細節(jié)的不同而差異很大，但它們通常導致阻塞、鎖存器爭用和超時、過長的響應(yīng)時間以及資源的過度利用。
阻塞 I/O 是指必須進行外部干預(yù)才能完成的 I/O 請求（通常是 I/O 請求包 (IRP)）。這種狀況通常需要執(zhí)行完整的系統(tǒng)重新啟動或類似操作才能解決，并且強烈表明硬件有故障或者在 I/O 路徑組件中存在程序錯誤。
延遲 I/O 是指無需干預(yù)即可完成但所花時間超過預(yù)期時間的 I/O 請求（同樣，這通常是 IRP）。這種狀況的原因通常是硬件配置、固件設(shè)置或篩選器驅(qū)動程序干預(yù)，需要硬件或軟件供應(yīng)商提供幫助以便跟蹤和解決。
SQL Server 2000 SP4 包含數(shù)據(jù)庫和日志文件 I/O（讀和寫）邏輯以便檢測延遲和阻塞狀況。當 I/O 操作經(jīng)過 15 秒鐘或更長時間仍未完成時，SQL Server 會檢測到并報告這一狀況。以下消息將被記錄到 SQL Server 錯誤日志中：
2004-11-11 00:21:25.26 spid1 SQL Serverhas encountered 192 occurrence(s) of IO requests taking longer than 15 seconds to complete on file [E:SEDATAstressdb5.ndf] in database [stressdb] (7). The OS file handle is 0x00000000000074D4. The offset of the latest long IO is: x00000000022000".
該消息表明，當前工作負載需求超出了 I/O 路徑或當前系統(tǒng)配置和功能，或者 I/O 路徑含有不能正常工作的軟件（固件、驅(qū)動程序）或硬件組件。
所記錄的錯誤信息提供了以下信息：
### occurrences — 未能在 15 秒鐘以內(nèi)完成讀或?qū)懖僮鞯?I/O 請求的數(shù)量。
File information — 完整的文件名、數(shù)據(jù)庫名和受影響文件的 DBID。
File handle — 該文件的操作系統(tǒng)句柄?？梢酝ㄟ^調(diào)試器和其他實用工具來使用這一信息跟蹤 IRP 請求。
Offset — 上一個阻塞或延遲 I/O 的偏移量?？梢酝ㄟ^調(diào)試器和其他實用工具來使用這一信息跟蹤 IRP 請求。（注：在記錄該消息的時候，該 I/O 可能不再阻塞或延遲。）
記錄與報告
I/O 的報告和記錄是按照文件執(zhí)行的。延遲和阻塞 I/O 請求的檢測和報告是兩個不同的操作。
檢測（記錄）是在 SQL Server 內(nèi)部的兩個位置處理的。***個位置是在 I/O 實際完成的時候。如果請求花費了 15 秒鐘以上，則發(fā)生記錄操作。第二個位置是在延遲寫入器進程執(zhí)行的時候。當延遲寫入器執(zhí)行時，它包含新的對所有掛起的數(shù)據(jù)和日志文件 I/O 請求進行檢查的操作，并且，如果已經(jīng)超過了 15 秒鐘的閾值，則會發(fā)生記錄操作。
報告是按照不低于 5 分鐘的時間間隔執(zhí)行的。當對文件進行下一次 I/O 請求時，發(fā)生報告操作。如果記錄操作已經(jīng)發(fā)生，并且自上一次報告發(fā)生以來已經(jīng)過去了 5 分鐘或更長時間，則向錯誤日志中寫入新的報告（上面顯示的錯誤消息）。
15 秒鐘的閾值當前是不可調(diào)整的。盡管不推薦這樣做，但您可以用跟蹤標志 830 完全禁用延遲和阻塞 I/O 檢測。在 SQL Server 啟動期間設(shè)置啟動參數(shù) –T830 可以禁用延遲/阻塞 I/O 檢測。使用 dbcc traceon(830, -1) 可以禁用對當前正在運行的 SQL Server 實例的檢測。只有重新啟動 SQL Server，Dbcc traceon 才會生效。
注：延遲或阻塞的給定 I/O 請求只會報告一次。如果消息報告 10 個 I/O 被延遲，則這 10 個報告不會再次發(fā)生。如果下一個消息報告 15 個 I/O 被阻塞，則表明 15 個新的 I/O 請求已經(jīng)被延遲。
檢測與解決 SQL Server 2000 SP4中問題之性能和計劃操作
總體系統(tǒng)性能可能在 I/O 處理中扮演關(guān)鍵的角色。在研究延遲或阻塞 I/O 的報告時，應(yīng)該考慮系統(tǒng)的綜合運行狀況。過多的負載可能導致整個系統(tǒng)（包括 I/O 處理）變慢。系統(tǒng)在發(fā)生問題時的行為可能是確定問題根源的關(guān)鍵所在。
例如，如果 CPU 利用率在發(fā)生問題時變高或者保持較高水平，則可能表明系統(tǒng)中的某個進程正在消耗如此之多的 CPU 時間，以至于它以各種方式對其他進程產(chǎn)生了消極影響。
請查看性能計數(shù)器 Average Disk Sec/Transfer 以及 Average Disk Queue Length 或 Current Disk Queue Length，以獲得特定的 I/O 路徑信息。例如，SQL Server 計算機上的 Average Disk Sec/Transfer 通常低于 15ms。如果該值上升，則可能表明 I/O 子系統(tǒng)無法滿足 I/O 要求。
請記住，SQL Server 充分利用了 Windows 的異步 I/O 功能，并且猛烈地擴展磁盤隊列長度，因此上述性能計數(shù)器具有較高的值本身并不表明存在問題。
檢測與解決 SQL Server 2000 SP4中問題之索引和并行性
特別常見的一種情況是，因為索引丟失以及由此導致的掃描、哈希和排序?qū)?I/O 系統(tǒng)造成的壓力，所以突發(fā)大量的 I/O。運行一遍“Index Turning Wizard”通常會有助于解決系統(tǒng)的 I/O 壓力。如果添加索引可以幫助查詢避免表掃描甚至排序或哈希，則系統(tǒng)可以獲得多個優(yōu)點：
減少完成操作所需的物理 I/O，這直接等效于提高查詢的性能。
數(shù)據(jù)緩存中只有較少的頁面必須周轉(zhuǎn)，因此緩存中的那些頁面可以一直與活動查詢相關(guān)。
避免不必要的排序和哈希。
可以降低 tempdb 利用率和減少爭用情況。
減少資源利用率和/或并行操作。因為 SQL Server 不能保證服務(wù)器在確定是否將查詢并行化時考慮并行查詢執(zhí)行和系統(tǒng)中的負載，所以您***針對串行執(zhí)行優(yōu)化所有查詢。在 Q/A 環(huán)境中，應(yīng)該將 max degree of parallelism 設(shè)置為 1，以便對根本沒有從服務(wù)器收到任何并行計劃的最糟糕情況強行進行調(diào)整。如果在測試環(huán)境中證實查詢可以按串行方式高效執(zhí)行，則生產(chǎn)環(huán)境中的并行計劃可以提供出乎意料的性能改進。但是，很多情況下，SQL Server 選擇并行執(zhí)行，這是因為要遍歷數(shù)據(jù)的絕對數(shù)量過于龐大。
該數(shù)據(jù)量通常直接受到索引的影響。例如，如果丟失索引，則可能產(chǎn)生大量排序操作。我們很容易就可以看出，執(zhí)行排序操作的多個輔助進程如何使響應(yīng)速度比以串行方式處理排序更快速，不過我們需要了解，該操作可能大幅增加 I/O 系統(tǒng)的壓力。
當多個輔助進程并發(fā)運行時，來自多個輔助進程的大型讀請求可能導致 I/O 突發(fā)以及 CPU 利用率提高。很多時候，如果添加了索引或者發(fā)生了其他調(diào)整操作，則可以調(diào)整查詢以使其更快地運行并使用更少的資源。這不僅提高了相關(guān)查詢的性能，而且還提高了系統(tǒng)的整體性能。
上述的相關(guān)內(nèi)容就是對檢測與解決 SQL Server 2000 SP4中問題的描述，希望會給你帶來一些幫助在此方面。
【編輯推薦】
