什麼是「調優強迫症」(CTD)？
Gaja Krishna Vaidyanatha (GKV) 在 2001 年提出「Compulsive Tuning Disorder」一詞，形容 DBA 沒有明確目標、盲目調整參數、追求「完美比率」卻忽略業務實際響應時間的行為。這種模式不但無效，還會掩蓋真實問題、導致方案不可重現。
核心原則：定義響應時間目標，達標即停止
- 性能足夠好的唯一標準： 應用響應時間滿足業務 SLA。
- 拒絕「檢查清單式調優」： 不要只因「緩存命中率不夠 99%」就調大 SGA；要問「哪個 SQL 花費時間最多？為什麼？」
- 數學驅動而非經驗驅動： 使用擴展 SQL 跟蹤 (10046 trace) 量化每個調用的耗時分布（CPU、I/O、鎖等待、網路等），針對最大佔比環節優化。
常見性能問題與診斷思路
| 問題類型 | 傳統誤區 | 科學做法 |
|---|
| 單一 SQL/作業緩慢 | 嘗試 8 個參數/索引/提示，碰巧解決 | 跟蹤該會話，分析 78% 時間花在 I/O → 定位具體物件/執行計畫 |
| 升級後效能退化 | 逐一調整數百個新參數 | 對比升級前後執行計畫、等待事件，鎖定 Optimizer 行為變化或 Bug |
| 系統整體緩慢 | 檢查所有比率、清單 | 資源剖析：將總響應時間分解為 Service Time (CPU) + Queue Time (Wait)，找出佔比最大的等待事件 |
Oracle 10g 提供的關鍵診斷設施
- 自動負載倉庫 (AWR) & 活動會話歷史 (ASH)：持續收集效能數據，無需手動開啟跟蹤。
- 自動資料庫診斷監視器 (ADDM)：自動分析 AWR/ASH，指出根因並給出建議，從「看比率」轉向「看時間」。
- 核心理念未變： 仍需 DBA 理解「響應時間 = 服務時間 + 排隊時間」，工具僅加速數據收集與分析。
最常見的調優迷思
- 調資料庫不調應用： 80% 以上問題源於應用 SQL/邏輯，調參數只能治標。
- 迷信「銀彈」參數： 沒有萬能參數，只有針對特定瓶頸的精確動作。
- 忽略網路/客戶端層： 端到端響應時間包含 Tier Time (網路、中介軟體、瀏覽器)，不可僅盯著資料庫。
醫生類比：精準診斷勝過全身掃描
病人說「右腳痛」，好醫生先看腳，不會直接開全身 CT+MRI+抽血。同理，DBA 應先定位「痛點 SQL/會話」，收集其跟蹤數據，而非對整個實例做無差別採樣。
行動指南
- 建立業務響應時間 SLA（如：核心交易 < 500ms）。
- 對未達標作業開啟 10046 Level 12 跟蹤或使用 ASH/AWR。
- 生成資源剖析表，按耗時降序排列（CPU、db file sequential read、log file sync、enq: TX - row lock contention…）。
- 針對 Top 1~2 環節：減少調用次數（改寫 SQL、加索引、調整應用邏輯）或降低單次耗時（優化 I/O 路徑、減少鎖持有時間）。
- 驗證改善量，達標即停止，避免過度調優。
