Oracle Data Guard 提供三種數據保護模式,分別針對「零數據丟失」、「高可用性」與「最高效能」三大核心需求。選型錯誤可能導致生產庫意外宕機或災難恢復時數據不可接受的丟失。本文深度剖析三種模式的運作機制、優劣勢對比、配置要求及生產環境選型建議。
| 模式 | 核心承諾 | Redo 傳輸機制 | Primary 影響 | Standby 故障後果 | 典型適用場景 |
|---|---|---|---|---|---|
| Maximum Protection (最高保護模式) |
絕對零數據丟失 (RPO=0) |
LGWR 同步 寫入 Standby Redo Log 才提交 |
高(需等待網絡/寫入確認) | Primary 強制 Shutdown | 金融核心交易、軍工國防等 容忍度極低的核心系統 |
| Maximum Availability (最高可用性模式) |
正常情況零丟失, 故障時自動降級保可用 |
LGWR 同步 (正常); 異步(Standby 故障時) |
中等(正常同步開銷) | 自動切換為 Performance 模式, Primary 存活 |
大多數企業核心業務 (ERP、CRM、計費系統等) |
| Maximum Performance (最高效能模式) |
Primary 效能優先, 允許數據延遲/丟失 |
LGWR/ARCH 異步 不等待 Standby 確認 |
極低(幾乎無感知) | Primary 正常運行, Standby 落後需人工介入 |
非核心報表、數據倉庫、 跨地域災備、頻寬受限環境 |
所有模式均通過 LOG_ARCHIVE_DEST_n 參數控制,核心屬性對比如下:
LOG_ARCHIVE_DEST_2='SERVICE=stdby LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby'
-- 典型異步高效能配置
LOG_ARCHIVE_DEST_2='SERVICE=stdby LGWR ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby'
-- 或使用 ARCH 進程
LOG_ARCHIVE_DEST_2='SERVICE=stdby ARCH VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby'

若 Standby 發生存儲故障、網絡中斷或負載過高導致 Redo 無法同步寫入,Primary 會在 NET_TIMEOUT(默認 30 秒)後強制 SHUTDOWN ABORT。這在生產環境中通常是不可接受的業務中斷。除非有極其可靠的雙活存儲與網絡冗余,否則強烈不建議生產環境使用此模式。
正常運行時同等於 Maximum Protection(零丟失),Standby 異常時自動降級為異步傳輸,Primary 不受影響。但需注意:
V$ARCHIVE_DEST_STATUS 確認同步狀態NET_TIMEOUT(建議 15-30 秒)雖 Primary 無感知,但需建立「延遲監控體系」:
V$DATAGUARD_STATS 中的 apply lag、transport lagALTER DATABASE RECOVER MANAGED STANDBY DATABASE 推進 Apply-- 切換至 Maximum Availability
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
-- 切換至 Maximum Protection
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
-- 切換至 Maximum Performance
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
切換後務必驗證 SELECT protection_mode, protection_level FROM v$database; 生效狀態。
Data Guard 保護模式的選擇本質上是業務 RPO/RTO 需求與基礎設施可靠性的博弈。對於 95% 的企業核心業務,Maximum Availability 是唯一正確的選擇——它在保障數據零丟失的同時,保留了 Primary 存活的底線。切記:沒有最好的模式,只有最適合當前業務與架構的模式。