前言：認清應用屬性再決策
系統屬於 **OLTP 為主、少量 OLAP** 混合負載。所有優化手段必須針對此屬性評估，否則事倍功半。
1. 共享服務器 (MTS) —— 別濫用
適用場景
- 併發連接數**超過作業系統進程上限** (如 32 位系統 1000+ 連接)。
- 會話極短、頻繁連斷 (需配合連接池)。
我們的誤區
以為 MTS 能「不加硬件就支撐更多連接」，實測性能下降、死鎖頻發。
核心缺點
- 代碼路徑更長，**天生比專用服務器慢**。
- 串行化處理，一個會話阻塞導致所有共享服務器阻塞，**人為死鎖風險高**。
- 長事務獨占共享資源，其他用戶饑餓。
- 功能受限：無法單獨啟停實例、無法介質恢復、無 Log Miner、SQL Trace 無意義。
- 內存轉移：省下 PGA 卻佔用 SGA Large Pool，**總內存未必降**。
建議
堅持默認專用服務器模式，連接不夠 → 加 CPU/內存/升 64 位。必要時混合模式 (部分會話專用，部分共享)。
2. RAC (Real Application Clusters) —— 不是銀彈
核心價值
- **橫向擴展 CPU/內存** (突破單機 4GB/CPU 數限制)。
- **高可用**：節點故障秒級切換，業務無感 (存儲層另論)。
隱形代價
全局緩存融合 (GC) 放大三大矛盾：
- **緩存爭用** (GC CR/Current Block 互傳)。
- **過量 I/O** (多份副本、日志同步)。
- **鎖放大** (全局 Enqueue、行級鎖跨節點協調)。
判斷標準
- 單機 CPU/內存已達上限，且應用**無熱點表/熱塊** → 考慮 RAC。
- 已存在 GC 爭用/高 I/O/鎖等待 → **上 RAC 會更慘**。
- 磁盤 I/O 負載均衡靠 RAID/ASM/存儲多路徑，**RAC 不解決 I/O 均衡**。
3. 分區表 —— 劃清 OLTP/OLAP 界限
- OLAP/數據倉庫：範圍/列表/哈希分區 + 分區剪枝 + 並行掃描 = **巨大收益**。
- OLTP 核心表：高併發單行/少量行訪問，**分區帶來額外元數據開銷、全局索引維護成本、跨分區事務複雜度**，收益往往為負。
- 歷史數據歸檔、滾動窗口場景 → 分區交換 (Partition Exchange) 秒級掛載/卸載，**真香**。
4. 並行查詢 (PX) —— 專為大掃描設計
- 適用：全表掃描、大索引掃描、大表連接、大排序/聚合、**數據倉庫報表**。
- 禁用：高併發 OLTP 核心交易路徑 (並行協調開銷大、消耗並行服務器進程、易導致 ORA-12805/資源耗盡)。
- 參數控制：
PARALLEL_DEGREE_POLICY=AUTO、PARALLEL_MAX_SERVERS、RESOURCE_MANAGER_PLAN 限制濫用。
總結：決策矩陣
| 技術 | OLTP 核心 | OLAP/報表 | 高可用需求 | 橫向擴展需求 |
|---|
| MTS | ❌ | ❌ | ❌ | ✅ (連接數超限) |
| RAC | ⚠️ (評估 GC) | ✅ | ✅ | ✅ |
| 分區 | ❌ (除歸檔) | ✅ | ✅ (滾動窗口) | ✅ |
| 並行查詢 | ❌ | ✅ | ❌ | ✅ |
鐵律：沒有通用最佳架構，只有**最適合當前業務模式**的架構。先畫像，再選型，持續觀測，動態調整。
