許多 IT 決策者對 Oracle RAC (Real Application Clusters) 存在錯誤期待，導致過度投資或架構缺口。本文針對四大核心誤區——**擴展性萬能、單機高可用、無需災難恢復、快速響應自動保證**——逐一澄清，並給出正確架構建議。
誤區一：RAC 是為了「水平擴展性」而生
真相：RAC 正統用途是 **Scale-Up (垂直擴展) 觸頂後的 Scale-Out (水平擴展)**。
- 現代單機：TB 級記憶體、百核 CPU、NVMe SSD，**單機即可支撐每秒數萬筆交易**。
- 只有 **極少數超大型 OLTP/資料倉庫** 才需 RAC 擴展寫入吞吐。
- 最佳實踐：**先把單機資源用盡 (Scale-Up)，再考慮 RAC (Scale-Out)**。
誤區二：RAC = 獨立的高可用解決方案
真相：RAC **僅防禦 Instance Failure (實例掛掉)**，無法防禦：
- 共享儲存故障 (需 RAID/多路徑/異地複寫)
- Interconnect 故障 (需雙網卡 Bonding)
- 資料損壞/人為誤刪 (需 Data Guard/備份)
- 機房級災難 (火災/水災/斷電，需異地 DR)
完整 HA 架構 = RAC + 多路徑儲存 + 冗余網路 + Data Guard/GoldenGate 異地備援 + 自動化 Failover 腳本。
誤區三：RAC 不需要災難恢復 (DR)
真相：RAC 節點通常同機房、距離 < 10km，**區域性災難 (颱風/地震/斷電) 會全掛**。
- 必須部署 **異地 DR**：Data Guard (同步/非同步)、GoldenGate 雙向複寫、存儲廠商遠端複寫 (DWDM Dark Fiber)。
- RAC 最佳實踐 **內建 DR 元件**，而非替代 DR。
誤區四：RAC 自動保證快速響應與 2 秒 Failover
真相：Failover 時間 = **偵測時間 + 重導向時間 + 交易重試時間**。
- 新交易必須 **< 1 秒** 完成，才能在 2 秒內完成 Failover 體驗。
- 應用端需實作 **Fast Connection Failover (FCF) / UCP / TAF**，並設定合理重試邏輯。
- 長跑交易 (大報表、批次) 無法快速 Failover，需業務接受度評估。
Cache Fusion 瓶頸：水平擴展的隱形天花板
- 節點間透過 Interconnect 交換記憶體區塊 (GC CR/Current Block)。
- Interconnect 頻寬/延遲不足 → GC 等待暴增 → **加節點反而降低效能**。
- 解法：應用改造減少熱點區塊、升級 10/25/100GbE Interconnect、採用 NVMe-oF 共享儲存。
RAC 採用決策樹
IF (單機 CPU/記憶體/IO 尚未飽和) THEN
推薦：單機 + Data Guard (成本最低、管理最簡)
ELSIF (寫入吞吐確實突破單機極限) THEN
推薦：RAC + Data Guard DR
前提：Interconnect 專用高速網、應用支援無狀態/冪等、團隊具 RAC 運維能力
ELSE
考慮：Sharding / 分庫分表 / 雲原生架構
END IF;
看清 RAC 的**能力邊界與前置條件**，才能在預算與 SLA 之間做出理性架構決策，避免「為了上 RAC 而上 RAC」的昂貴教訓。
