效能調教概論 (Performance Tuning Overview)

無庸置疑的，效能問題（Performance issue）一直是大部分 DBA 心中揮之不去的夢靨。遺憾的是，這夢靨是沒有終止的一天，能做的只是儘量去減少發生的頻率與程度以及持續的時間。

廣義上來講，效能問題指的是系統回應（response time）時間過長或資料吞吐量（throughput）過低。而效能調教（performance tuning）便是找出造成效能問題的瓶頸（bottleneck）並採取適當的調整來減低或消除因瓶頸所造成的影響。

效能調教主要可分為 Instance Tuning 與 SQL Tuning 兩大方向，但在實際進行調整前，若能先擬定一份效能規劃(Performance Planning)，將可更精準化效能調教帶來的實際效益。

效能規劃包含了"效能設計開發"以及"效能改善方法"。最佳的效能設計開始於系統初始階段並持續在整個系統的生命週期。因此，在系統設計階段若能將效能問題納入規劃，將有助於系統上線後的效能調教。

然而，根據筆者的經驗，絕大多數的系統在設計開發階段，礙於成本考量、時間壓力或技術門檻，往往不會將效能問題納入考量。而且在系統上線初期，資料的累積並不多或功能需求單純，因此也不一定會有效能上的問題。然而當系統運行一段時間，資料累積至某一數量後，效能問題就開始被彰顯出來。

找出使用者認知上的系統預期效能並給予一個明確的定義是執行效能改善方法的前提。典型的使用者反應效能問題範例，大概如下：
# 系統效能太差了，我們都沒辦法做事了
# 這個帳務系統跑太久了
# 系統回應太慢，客戶已經不耐煩了
# 系統要越快越好

將這些使用者的回饋轉化成符合實際的目標，將是影響效能調教是否成功的關鍵，例如：
# 月初的結帳必須在 3 個小時內完成
# 客戶資料查詢結果須在 20 秒內產生
# 網頁的更新時間不得超過 5 秒

當與使用者達成確切調整目標的共識後，就可以開始執行改善方法。然而，面對著複雜及差異化的系統，如何快速準確的找出效能瓶頸也是對 DBA 的一大挑戰。以下為 Oracle 官方建議的步驟：
1. 執行下列幾項標準檢查：
　1.1 取得使用者的回饋，決定調整的範圍與目標
　1.2 蒐集系統、資料庫及應用程式在正常與異常情況下的效能數據
　1.3 對整個系統進行一次健全性檢查（sanity-check），特別是系統資源使用率與硬體狀態診斷部分
2. 檢查 10 大資料庫最常見的錯誤，找出症狀（symptom）並分析蒐集到的資料。
3. 以症狀為依據，建立一個概念模型（Conceptual Model），幫助了解導致效能問題的原因。
4. 提出解決方案並進行實際調整。這其中最重要的準則就是：同一時間內只進行一個項目的調整並衡量所造成的效果。
5. 確認調整是否有效並滿足使用者預期。若效果不彰，嘗試找出其他的瓶頸，並持續修正概念模型。
6. 持續 3~5 這三個步驟，直到達成預期效能調整目標。

若是突發性的效能問題，處理方法也會有所差異，但主要是根據以下的步驟來處理：
1. 詢問使用者或管理者「是否有對系統進行任何的變動」？來取得線索。但有時候得到的回答並無法協助釐清問題，此時，DBA 應該試著蒐集檢查發生前與發生後的統計資料或 log 檔。
2. 針對硬體進行健全性檢查，觀察 CPU 使用率，檢查磁碟、記憶體和網路效能。
3. 判斷效能問題是由 CPU 使用率或是 wait events 引起。
4. 採取緊急措施來穩定系統。例如將非核心應用程式設定離線或限制系統資源的使用。這些動作也包括了重新啟動系統或是中斷某些正在執行的程序。
5. 確認系統是否趨穩並採用前面所提到的一般效能調整方法來進行處理。

由於 Instance Tuning 與 SQL Tuning 牽涉的範圍太廣，將再擇期討論。