資料庫優化流程

xz43發表於2011-01-18
資料庫優化
1。資料採集
 
    制定完優化目標後，需要進一步對系統中的資料進行採集和分析。資料採集包括作業系統資料和資料庫的資料。
    對於作業系統資料的採集，可以使用vmstat、top、sar、iostat、netstat等工具進行。
    對於資料庫資料的採集，可是通過多種方式進行。如STATSPACK分析，而對於oracle10g的話，還可以使用AWR報告、ADDM報告和ASH報告。
    OEM中的診斷包和調優包是採集資料庫狀態資訊的很有效的工具。使用OEM的實時監控工具的挖掘功能，可以很方便地進行問題定位。
    很多DBA都有一些採集資料的獨門祕笈，根據不同的資料庫的情況，準備一些資料庫效能狀態採集的指令碼是十分必要的。作為效能調優人員，應該準備以下方面的資料庫指令碼：
  a、資料庫主要表、索引、分割槽、表空間等情況的資訊採集指令碼；
  b、資料庫表的主要約束關係情況的採集指令碼；
  c、獲取某個資料庫物件的DDL語句的指令碼；
  d、資料庫引數的採集指令碼（包含隱含引數）；
  e、主要緩衝區命中率情況的採集指令碼；
  f、SQL緩衝區分析指令碼；
  g、獲取長時間執行的SQL指令碼；
  h、共享池分析的指令碼；
  i、系統等待事件分析的指令碼；
  j、閂鎖競爭情況採集指令碼；
  k、主要檔案I/O效能分析的指令碼；
  l、Top會話分析的指令碼；
  m、會話跟蹤的指令碼；
  n、OPS/RAC效能分析的指令碼（可以使用Oracle提供的分析指令碼，在？/rdbms目錄下）；
  o、表空間碎片分析的指令碼；
    以上指令碼中，部分可以在rdbms目錄下找得。另外，Metalink上也有大量指令碼可以參考。每個DBA都應該根據自己維護的資料庫的特點，積累自己的“獨門祕笈”。
    採集資料是一個十分嚴密的過程。應該在資料庫的不同狀態點（或者時間點）進行多次資料採集，而且相同的狀態點（或者時間點）最好進行多次採集，並進行對比，找出共同點。差別比較大的話，就要繼續採集，直到所有的資料庫狀態可以被清晰地分析出來為止。
    另外，在採集資料的時候，要注意像交響樂一樣，每個系統都有自己獨特的“節奏”的，這裡所說的“節奏”其實就是每個系統獨有的執行特徵。每個系統的閒時、忙時、業務高峰都有一定的特徵，在某個時間段執行的程式也有一定的規律。系統的節奏決定整個優化專案進場的時間。如果進場時間未能根據系統的節奏進行安排，我們甚至可能白白浪費時間。
 
2。優化方案
 
    所有的資料庫和系統狀態都已經採集完畢，並確認資料準確以後，就需要對這些資料進行進一步的分析，通過分析制訂出優化計劃。這時，可能會發現需要採集更多資料才能夠定位問題，因此就要進行資料補充，直到所有資料都能夠分析清楚，並形成有針對性的優化方案為止。
    制訂優化計劃一般來說無法由一個人完成，而要由一個專家團隊來完成。某方面的專家可以提出自己對某個專題的計劃，最後彙總為一個統一的計劃。計劃形成後，需要由一個專業的技術小組來稽核該計劃。專業小組應該包括下列人員：
  應用開發方的技術代表；
  小型機（伺服器）技術專家；
  網路管理員；
  Oracle專家和DBA；
  系統架構師；
  使用者代表；
 
一份優化計劃應該包括：
  系統軟硬體及網路調整和資料庫調整方案；
  優化方案涉及的所有指令碼；
  詳盡的系統優化操作時間表，需要列出每個步驟的起始和終止時間；
  優化完成後的檢查方案（含指令碼）；
  優化過程出現問題的處理預案；
 
    在制訂優化實施計劃時，一定要考慮保留足夠的時間進行必要的備份和保留系統檢查及回退的時間。
    優化工作不可能100％順利完成，而DBA的責任是報障在任何情況下，系統都能夠正常執行。因此，優化計劃應該包含足夠的應急預案，以應對在優化工作中碰到的各種異常情況。應急預案應考慮以下情況：
  優化工作進度遲緩，無法按時完成；
  發現優化工作無法達到預期目標，甚至可能引起新的效能問題；
  資料庫補丁無法正常完成；
  資料庫無法正常工作；
  資料庫崩潰；
  系統硬體發生故障；
 。。。
    所有和本次優化相關的可能出現的問題，都應該根據出現的概率和危害程度制訂相關的應急預案。對於危害越大的情況，應急預案也應該越完備。千萬不可有僥倖心理。
 
3。實施優化計劃
 
    優化計劃的實施一般來說會安排在晚上或者週末進行。有些優化不需要停機進行，而有些優化需要停止或者重啟資料庫，有些優化需要消耗相當長的時間（比如表或索引儲存結構重組）。
    實施優化計劃前，許亞向專案組提出申請，並由專案組協助安排優化時間。在完成必要的備份等準備工作後再進行實施。實施過程需隨時對進度進行稽核，發現進度慢於預案的進度估算，甚至可能發生無法在規定停機時間內完成的情況，就需要及時調整方案甚至及時停止實施，比較嚴重的還要根據應急預案立即恢復。
    實施過程中，最好整理有個實施檢查表（checklist），完成時，再檢視檢查表的所有步驟是否都已完成。
 
4。優化後評估
 
    優化方案實施後，應該安排DBA對資料庫進行24小時～72小時的實時觀察（根據系統規模不同，實時觀察的時間長短也不同）。觀察的內容應該包括系統級和應用級兩個方面，系統級觀察包括：
  系統CPU使用情況；
  系統I/O情況；
  系統記憶體情況；
  系統網路情況；
  資料庫整體負載情況；
  資料庫平均SQL響應時間；
  關鍵業務SQL的執行計劃；
  資料庫平均事務響應時間；
  主要等待事件；
  資料庫I/O情況。
    除了觀察系統狀況外，還需要對應用系統進行觀察，檢視相關應用系統總體的工作狀態是否正常。再優化實施之前，應該將對系統影響較大的SQL以及關鍵業務的主要SQL的執行狀態和執行計劃都採集下來，優化完成後，對這些SQL的執行情況進行對比。
 
    一般來說優化不是一次就能夠完成的，上述過程需要進行多次迴圈，直到所有的優化目標都已經達到才停止。在這個過程中，也需要對優化目標進行一些修正，如果最初設定的目標實現起來存在風險或者根本無法達到，那麼就需要儘快修正優化目標。
 
下面是一個系統優化前後比較的例子
指標名 舊系統情況 當前情況 變化對比 備註
系統CPU 30％～60％ 60%～90％ 比以前加大30％ CPU使用率明顯提高
系統記憶體 90% 90% 0% 變化不大
系統I/O等待 40％～50％ 0～30％ 大幅度減少 目前基本處於正常狀態
響應時間 11.47s 3.18s 加快3.37倍 　
事務數/秒 3.51 9.38 提高2倍多 　

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

相關文章