OLTP效能調整與最佳化--結語
根據軟體生命週期的瀑布模型,應用程式的效能在其設計階段就已經有了質的定性。如果在應用程式開發完成之後才想到最佳化,一般就只能治標不治本,在遇到嚴重的效能問題時,甚至需要將整個軟體推倒重來。
當一個軟體系統已經上線運營,在資料庫引擎方面需要最佳化時,可以按以下建議執行。
一、需求分析與設計
在進行效能調優之前,務必有詳細的需求分析。需求分析應當包括:
1.業務需求與流程重整
充分瞭解業務的流程,並從流程最佳化開始。需求分析和設計人員不是照搬現有的流程,而是利用最新的電腦技術改造現有的商務程序,實現正常化、效率化的目標。
業務需求應充分展望和預測未來的電腦技術和軟體系統可能承受的運行壓力,至少要能應付未來一段時期的資料增長和使用者訪問的壓力。如果效能最佳化只是滿足一時的需求,不久又要重新最佳化,那麼這種最佳化的必要性就值得商榷了。
2.投資額度與最佳化目標
效能調整與最佳化項目所創造的價值,很難以現有的商業價值評估體系進行測算,因此很難計算投資報酬率ROI)。
一般來說,效能最佳化是無止盡的,需要“見好就收”,在投資額度內達到預期的效能目標就足夠了。
二、實施方法
1.分析瓶頸
掌握SQL Server的工作原理,從底層去瞭解產生瓶頸的原因,然後做出對策。一般的瓶頸出現在:
1)伺服器硬體
2)作業系統
3)SQLServer選項
4)記憶體、CPU、磁碟I/O
2.分段實施
1)第一階段:建立效能基準
為當前的SQLServer系統建立效能標準,並且儘可能地量化,以此作為評估效果的依據。例如,通過效能計數器獲得當前的記憶體、CPU峰值和均值。又如,運行一個複雜查詢,記錄它的耗時。
2)第二階段:最佳化系統資源
例如,為32位系統啟用AWE。這是最簡單的工作,也是最有意義的工作,它能為效能調優項目帶來顯而易見的效果。如果是伺服器硬體瓶頸記憶體不足、磁碟效能低,等等),或者是作業系統瓶頸32位作業系統),將SQLServer遷移到新的伺服器,或者重新安裝作業系統,在某些情況下都可以明顯提升效能。
3)第三階段:依次解決瓶頸
使用計數器、DMV、跟蹤等技術手段,確認瓶頸,然後對症下藥。
4)第四階段:最佳化T-SQL語句
程式開發人員如果不具備查詢最佳化知識,或者對SQLServer瓶頸瞭解不多,往往導致最終交付的品質可能參差不齊。甚至在國內某些企業,招募幾個“碼農”就包攬需求分析、模型設計、編寫代碼、測試上線的“一條龍”服務,其代碼的品質可想而知。
本文出自 “我們一起追過的MSSQL” 部落格,轉載請與作者聯絡!