從 AWR 到性能模型：量化 DB Time、邏輯讀、IO 延遲與 CPU 容量
如何為數據庫建立可量化、可預測的性能模型？本文提出以響應時間為核心，拆解 Oracle 時間模型，建立「邏輯讀 - 響應時間」映射，定義 IO/CPU 瓶頸判斷閾值，並給出容量規劃與風險預測的實戰經驗值。
一、響應時間：性能評價的唯一標準
響應時間 = 服務時間 + 等待時間。所有優化最終目標：降低響應時間，提高單位時間吞吐。
二、Oracle 時間模型（AWR 核心視角）
DB Time = Σ (SQL execute elapsed time, parse time, PL/SQL execution, ...)
= DB CPU + Wait Time (User I/O, Commit, Concurrency, ...)
AWR 報告關鍵指標：
- DB Time：用戶進程總活躍時間。
- DB CPU：前台進程佔用 CPU 時間。
- User I/O：用戶進程等待 IO（db file sequential/scattered read）。
- Commit：log file sync 等待（LGWR 寫 redo）。
三、系統分型：CPU 密集 vs IO 密集
| 類型 | DB CPU 佔比 | User I/O 佔比 | 典型特徵 |
|---|
| CPU 密集型 | > 85% | < 10% | 複雜計算、大量排序/哈希、硬解析 |
| IO 密集型 | < 15% | > 80% | 大表全掃、索引缺失、緩存命中率低 |
| 混合型 | 20%-60% | 10%-60% | 大多數生產系統 |
四、物理 IO 響應時間經驗閾值
- db file sequential read（單塊隨機讀）：≤ 10 ms 為正常，> 10 ms 判定存儲延遲過高。
- db file scattered read（多塊順序讀）：≤ 10 ms 正常。
- log file sync（提交同步）：≤ 5 ms 嚴格要求，直接決定寫入響應上限。
原理：機械磁盤延遲 = 尋道時間 + 旋轉延遲，隨機/順序讀 8K/128K 差異極小，均受限於機械特性。
五、邏輯讀 - 響應時間經驗模型
核心假設：充分調優系統中，非 CPU/IO 等待 < 10% DB Time。
| 系統類型 | User I/O 佔比 | DB CPU 佔比 | 每邏輯讀響應時間 |
|---|
| IO 密集型 | 85% | 5% | 0.1 - 0.5 ms |
| CPU 密集型 | 10% | 85% | < 0.01 ms |
| 混合型 | 60% | 20% | 0.05 - 0.1 ms |
計算公式：DB Time / 邏輯讀總數 = 平均每邏輯讀響應時間。隨 IO 佔比升高，單邏輯讀延遲顯著增大。
六、容量瓶頸預測與擴容決策
- IO 子系統建模：
- 單盤 IOPS 上限（15K SAS ≈ 150 IOPS @ <10ms）。
- 壓測建立「IOPS - 延遲」曲線，確定性能拐點。
- AWR 監控
Physical Reads/sec 趨勢，提前擴容。
- CPU 容量核算：
- 理論 CPU 秒/小時 = 3600 × 核心數。
- 預留 10-20% 給 OS（sys%），用戶進程可用 ≤ 80%。
- DB CPU 趨勢逼近上限時觸發擴容/調優。
七、並發訪問的隱性代價
- Latch 爭用：熱塊（CBC latch）導致 spin（燒 CPU）+ sleep（增等待）。
- 一致性讀構造 CR 塊：高並發修改 + 長查詢 → 大量 UNDO 適用 → 邏輯讀爆增 → CPU 飆升。
- 存儲熱點：RAID/ASM Rebalance 分散熱點塊。
- 串行化瓶頸：Latch/Enqueue/Mutex 為一致性付出的代價，優化目標是最小化串行區域。
八、優化原則與健康度判斷
基於響應時間的優化原則：盡量減少等待時間，提高服務時間效率。
- 若非 CPU/IO 等待 > 5% DB Time → 存在具體等待事件問題，需針對性分析（AWR Top Events / ASH）。
- 每個 DBA 應能從 AWR 秒出：系統類型、瓶頸點、單邏輯讀延遲、IOPS 餘量、CPU 餘量。
九、給 DBA 的行動清單
- 導出最近 AWR，填寫上述三類型表格，定性本庫屬性。
- 記錄
sequential read、log file sync 平均延遲，對標 10ms/5ms。
- 計算
DB Time / Logical Reads，對照經驗值判斷優化空間。
- 壓測存儲得出 IOPS-延遲曲線，設定告警閾值（如 80% IOPS 觸發擴容評估）。
- 建立「SQL 上線前審核模型」：預估邏輯讀 × 經驗延遲 = 預期響應時間，超標即駁回。
性能模型非一蹴而就，但在 AWR 數據與經驗值加持下，每位 DBA 都能構建屬於自己的「性能指南針」，在容量規劃、風險預警、SQL 治理中做到心中有數。
