響應時間分解公式
Rt (端到端響應時間) = Ts (服務時間) + Tw (排隊時間)
Ts = CPU 時間 = Oracle 核心代碼執行時間
Tw = ORAt (Oracle 等待時間) + TIERt (網路/中介層/瀏覽器時間)
關鍵洞見：有限 vs 無限
| 維度 | 服務時間 (Ts) | 排隊時間 (Tw) |
|---|
| 本質 | CPU 執行指令 | 等待資源 (I/O、鎖、閂、網路) |
| 上限 | 有限：N CPU × 60 秒/分 | 無限：隨負載無上界增長 |
| 瓶頸表現 | CPU 100% 時無法再增加吞吐 | 負載增大時排隊指數級上升 |
實戰案例：某小時級效能數據分析
- 採樣間隔 1 小時，收集
V$SYSTEM_EVENT (排隊) + V$SYSSTAT (CPU)。
- 圖表顯示：午餐時段 CPU 耗用 ~1000 分鐘/時，推算至少 17 CPU (1000/60)。
- 若 OS 監控顯示 CPU 利用率僅 50%，推算實體 CPU 約 34 顆。
- 關鍵發現：CPU 尚未飽和 (僅 50%)，但響應時間惡化 → 瓶頸在 I/O 或鎖等待 (排隊時間)，而非 CPU (服務時間)。
診斷流程
- 確認 CPU 總容量 (核心數 × 60 秒/分)。
- 計算當前 CPU 使用率 = 實際 CPU 分鐘 / 總 CPU 分鐘。
- 若使用率 < 80% 但響應時間差 → 排查 Top Wait Events (I/O、Lock、Latch)。
- 若使用率 ≈ 100% → 優化 SQL 減少邏輯讀、或增加 CPU/調整並行度。
團隊溝通價值
「服務時間有限、排隊時間無限」是極佳的溝通模型：
- 讓非技術干系人理解為何「加 CPU」不一定解決緩慢。
- 將調優焦點從「調參數」轉向「減少等待事件發生次數」。
- 建立可量化、可預測的效能改善預期，增強信任。
