國際 Oracle 用戶組 (IOUG) 經驗顯示：幾乎所有生產系統仍有效能提升空間，「已調優到極致」極罕見。關鍵在於採用自底向上、端到端的系統堆疊分析法，而非單純依賴檢查清單。
| 傳統認知 | 實戰發現 | 行動建議 |
|---|---|---|
| 大部分改善在應用層 | 系統堆疊各層皆有顯著機會，無統計顯著層級差異 | 全堆疊分析：OS、儲存、網路、實例、SQL、應用 |
| 平均 2 天完成調優 | 最少需 12 天：啟動會議、資料蒐集、分析、驗證、文件化 | 納入專案管理，預留完整週期，重視文件化 |
| OLTP 碎片不影響效能 | 定期重組消除碎片常帶來巨大改善 | 納入維護窗口定期重組，關注 ASSM 表空間管理 |
| 緩衝 I/O 非大問題，調磁碟 I/O | 磁碟 I/O 成本約為邏輯 I/O 70 倍 (非傳說 10,000 倍)，但高邏輯 I/O 限制擴展性 | 同步關注降低邏輯 I/O (SQL 調優) 與優化實體 I/O |
| OA Tablespace 合併帶來即時改善 | 概念上合理，但工具組成熟度待驗證，白板推演需實測 | 謹慎評估，先在測試環境驗證 |
| 客戶端磁碟重組提升效能 | 現為瘦客戶端/瀏覽器時代，客戶端重組無效 | 專注伺服器端與網路路徑優化 |
| 打補丁解決效能問題 | 補丁常引入不穩定，依賴鏈複雜，非首選 | 根因分析優先，補丁作為最後手段並充分測試 |
V$SQLAREA — IT 主管應隨時詢問 DBA 本周查詢此視圖次數TKPROF 處理巨大 Trace 檔 (10GB+ 級別)配置規格：750 MHz CPU、256 MB RAM、Win2K Enterprise、獨立邏輯磁碟、JInitiator 鎖定版、Office 2003、無桌布/螢幕保護/工具列/常駐程式。流程：用戶桌面實測 → 機房直連中間層再測 → 消除主觀性雙向偏差。
舊版建議單表索引 ≤ 5 個；現代指南：Oracle 不限制索引數，**若新增索引能降低高頻 SQL 的 I/O，即應建立**，實務上單表 30+ 索引常見。
2 × CPU 核心數V$SQLAREA、Statspack/AWR 找出真兇
