核心機制：主備同步的三種傳輸模式
Oracle 9i Data Guard 透過待命資料庫防範資料災難。其核心在於將主資料庫的重做日誌傳輸並應用至待命端，實現同步。根據業務對資料零損失與效能的取捨，提供三種模式：
- 同步寫入：重做日誌同步寫入待命端，提供零資料損失保護，但會影響主庫效能。
- 非同步寫入：歸檔日誌非同步傳輸，主庫效能損失極小，資料損失風險極低。
- 延遲應用：日誌到達後延遲一段時間再應用，可防止主庫邏輯錯誤快速傳播至備庫，但會增加容錯移轉時間。
四大資料保護等級
| 保護等級 | 核心規則 | 資料損失 | 效能影響 |
|---|
| Guaranteed Protection（最高） | 主庫修改時至少一備庫有效；連線中斷即停止主庫 | 零 | 大 |
| Instant Protection | 主庫修改時至少一備庫有效；連線中斷允許不一致，恢復後解決 | 極小 | 小 |
| Rapid Protection | 修改快速應用於備庫 | 可能 | 極小 |
| Delayed Protection | 修改延遲應用於備庫 | 等同未歸檔線上日誌量 | 極小 |
限制資料損失量的關鍵參數與技術
- Standby Zero Data Loss（LGWR 同步寫入）：LGWR 在寫入本地線上日誌的同時同步傳送至待命端，本質上是遠端重做日誌鏡像，代價是顯著效能損耗。
- ARCHIVE_LAG_TARGET：設定日誌從產生到傳送至待命端的時間上限（建議 1800 秒）。注意：長交易會導致更多已提交交易未傳送而丟失。
演進脈絡：從 Oracle 8 Standby 到 Data Guard
Oracle 9i 將 8i 的自動化待命資料庫功能大幅增強，並整合防使用者錯誤、防癱瘓模組，統稱為 Data Guard。主要進步包括：自動化管理、監控告警機制、角色轉換簡化、硬體軟體升級停機時間極小化。
物理待命 vs 邏輯待命
| 特性 | 物理待命資料庫 | 邏輯待命資料庫 |
|---|
| 結構 | 區塊層級完全同步，結構與主庫完全一致 | 將歸檔日誌轉為 SQL 交易應用，物理結構可不同 |
| 開放模式 | 唯讀或恢復模式 | 可讀寫開放 |
| 額外價值 | 單純災備 | 可建立不同索引/物化視圖，支援決策支援查詢 |
| 技能要求 | 較低 | 較高 |
極致保護方案通常結合兩者：物理待命提供高可用與快速容錯移轉，邏輯待命分擔報表查詢並提供邏輯層面的資料驗證。
角色轉換：Failover 與 Switchover
- Failover（故障切換）：主庫故障無法恢復時，強制將備庫升為主庫。特點：不可逆、可能丟失資料（除非最高保護模式）、原主庫與其他備庫需重建。
- Switchover（切換）：主庫正常時計劃性角色互換。特點：零資料損失、無需重建實例、支援平滑升級維護、可頻繁執行。
關鍵元件架構
- 日誌傳輸服務：核心傳輸引擎，支援多種模式、錯誤處理、間隙解析。
- Data Guard Broker：統一管理介面，單一指令完成容錯移轉，支援 OEM 圖形化與 CLI 兩種操作模式。
- LogMiner：邏輯待命的基礎架構，支援 SQL 層面的日誌分析與挖掘。
- Disaster Recovery Server (DR Server)：鬆散耦合的節點群，整合物理/邏輯待命為單一可管理解決方案，提供高可用性資源組與分散式計算框架。
