深入SQL Server資料庫速度提升問題（一）

　　SQL伺服器的效能管理通常是反應式的，它側重的是伺服器的執行狀態。資料庫管理員會對問題作出響應而不是將避免問題的產生擺在首位。可視性也很大程度上僅限於觀測資料庫伺服器而不是瞭解SQL伺服器怎樣直接對程式使用者的產生影響。

　　等待時間分析是對SQL伺服器資料庫效能的一種改進方法，它不再只是監測系統的執行狀況而已，等待時間分析側重於應用程式響應詢問所需的時間。其結果是一種能夠迅速回答關鍵問題的分析技巧，如為什麼資料庫要讓使用者進行等待，我們又可以為此做些什麼呢?

　　由於輕量級監測技術和無代理架構的發展，等待時間分析現在已經可以應用與實際操作了。它利用了SQL伺服器中新裝置來暴露等待型別，這些步驟在SQL伺服器處理詢問時積累延時。

　　事半功倍

　　對於IT機構來說，使用等待時間分析的結果可以減少資料庫操作的成本並改進IT服務。資料庫管理員可以用更少的伺服器完成更多的工作。從SQL Server 2000到2005再到2008，開發週期縮短了。對於那些要用更少的資源提供更優質服務的IT公司來說，等待時間分析是實現成本效益的答案。

　　資料庫管理員通常位於兩難的境地。對於響應程式使用者的資料庫來說，他們的數量是有限的，但是他們卻不能看到資料庫減緩的原因。通常這樣的事情根本不是發生在其資料庫中，但是卻源於應用程式程式碼，網路或者系統架構。為了獲取改變的應用程式程式碼，資料管理器必須為程式設計師提供證據，與此同時，程式設計師會感到十分疑惑因為他們並不瞭解資料庫。這些問題是典型的依賴於舊式伺服器狀態監測技術的表現。

　　等待時間分析

　　有效的等待時間分析不僅僅是擷取等待型別的資料。為了能有效地在模糊資料點中生成有用資訊，它必須利用商業智慧情境中驗證過的技術。其中關鍵的概念包括：

• 測量時間，不要考慮操作 對於應用程式使用者，I/O操作或邏輯讀取的數量已經沒有什麼意義。重要的是應用程式響應所需的時間。從這一角度來實現優化要側重於資料庫所需的時間。等待類所做的就是這一操作。
• 注意查詢 問題的關鍵是SQL查詢級別的測量和單獨對話。測量通過實體或資料庫的等待而不會減緩其速度的工具不會給出有價值的資訊。
• 持續捕獲 整個過程中要時刻保持監視。通過觀測所有的對話，資料庫管理員可以發現任何問題。當使用者因為程式速度減慢而尋求幫助的時候，資料肯定已經準備好了。依賴於間歇性追蹤的系統將錯過可能發生的錯誤。
• 歷史地觀測 要明白需要修復什麼，資料庫管理員應該研究資料庫的趨勢和變化，而不只是看到即時結果。有效的等待時間分析用歷史的眼光來比較當前等待類的統計資料和以前的統計以便發現其中的不同之處，這有助於解決潛在的新問題。

　　SQL Server等待類

　　意識到SQL 伺服器等待類是瞭解該方法的第一步。任何有悖於SQL伺服器執行的語句都將面對等待，因為SQL伺服器會為要完成的命令按照順序訪問資源。請求會等待要檢索的，要寫入磁碟或是要寫入SQL伺服器日誌的資料。當等待變成一個長期過程或超量時，就會出現效能問題了。

　　普通等待類

　　SQL伺服器會記錄類的資訊以及等待程式的持續時間。雖然在SQL伺服器中有100多種類，但是其中可能只有少數會出現問題。任何等待類都以LCK_開始，這意味著該任務在等待獲得一個鎖定。例如，一個LCK_M_IX的等待類意味著等待獲取Intent Exclusive鎖定。20多種等待類是鎖定等待，這些等待之所以恰當是因為SQL伺服器中大多數執行的任務要求某種鎖定。下一個最普遍的鎖定種類是ASYNC_IO_COMPLETION和ASYNC_NETWORK_IO。前一個是等待I/O操作完成的等待，後一個是等待I/O在網路上完成的等待。最後，留意一下CXPACKET等待狀態。當某一程式試圖使查詢處理器交換迭代同步時會出現這一等待。這說明了伺服器並行設定問題。花時間弄清楚怎樣的潛在等待狀態是耗時的。平均來說，大約20種潛在等待狀態表現了80%的問題。在完成等待時間分析之後，你就習慣某些等待類了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-600461/，如需轉載，請註明出處，否則將追究法律責任。