Oracle Redo 機制核心原理：Redo Log Buffer、LGWR、Checkpoint 協同保障事務持久化與故障恢復

一、 核心組件架構：Redo 寫入鏈路

用戶進程 (Server Process)
      │
      ▼ 生成 Redo Entries (變更向量)
┌─────────────────────────────────────┐
│      SGA: Redo Log Buffer           │  ← 循環內存緩衝區
│  (STRANDs 多公共重做線程, 10g+)     │
└─────────────────────────────────────┘
      │ LGWR (Log Writer) 後台進程
      ▼ 批量寫入 (Group Commit)
┌─────────────────────────────────────┐
│      Online Redo Log Files          │  ← 多路復用組
│  (Group 1: log1a, log1b | Group 2...)│
└─────────────────────────────────────┘
      │ ARCn (Archiver) 進程 (歸檔模式)
      ▼ 複製歸檔
┌─────────────────────────────────────┐
│      Archived Redo Log Files        │  ← 異地備份/備庫同步
└─────────────────────────────────────┘

二、 Redo Log Buffer：高併發寫入優化

1. 結構特點

• 循環緩衝區： 寫入指針繞回覆蓋最舊未歸檔/未檢查點的 Redo。
• 多 Strand (10g+)： 每 CPU 核心/邏輯 CPU 一個 Redo Allocation Latch + 獨立 Strand，消除單 Latch 爭用，**線性擴展重做生成吞吐**。
• Redo Entries (Redo Records)： 原子變更單元，含：數據塊變更向量、Undo 塊變更、事務元數據 (SCN、XID、OPCODE)。

2. 寫入觸發條件 (LGWR 喚醒)

1. 事務提交 (COMMIT)： **最核心觸發**，LGWR 確保該事務 Redo 持久化到磁盤 (配置 `COMMIT_WRITE` 影響)。
2. Buffer 達閾值： 佔用空間 > 1/3 Buffer 大小，或含有 > 1MB Redo。
3. 超時： 每 3 秒 (默認) 定時喚醒。
4. Checkpoint / Log Switch： CKPT 進程通知 LGWR 刷新。
5. 並行查詢 / 直接路徑載入： 大量 Redo 產生時主動觸發。

3. Group Commit (組提交) 優化

• 多個事務近乎同時提交，LGWR **單次 I/O 批量寫入多個事務的 Redo**，攤銷 `fsync` 開銷。
• 10g+ `_log_io_size` / `COMMIT_WRITE` (NOWAIT/BATCH) 可調優行為，**生產建議默認 (WAIT/IMMEDIATE) 保證持久性**。

三、 LGWR 與多路復用 Redo Log 組

1. 組與成員

• 最少 2 組，建議 3-5 組。每組 2+ 個成員 (多路徑/不同磁盤/控制器) 防單點損壞。
• LGWR **同步寫入組內所有成員**，任一成員寫入失敗 → 該組標記 `INVALID`，LGWR 繼續寫入其他組，Alert 日志報錯。

2. Log Switch (日志切換) 與 Checkpoint 綁定

當前組寫滿 (或 ALTER SYSTEM SWITCH LOGFILE)
      │
      ▼
LGWR 切換至下一組 (CURRENT → ACTIVE → CURRENT)
      │
      ├──▶ 觸發 Checkpoint (CKPT 進程)
      │       │
      │       ▼
      │   DBWR 將該組保護的所有「髒塊」寫回數據文件
      │       │
      │       ▼
      │   CKPT 更新控制文件 + 數據文件頭 Checkpoint SCN
      │
      └──▶ ARCn 歸檔該組 (歸檔模式)
              │
              ▼
         歸檔完成前，該組不可被覆蓋 (STATUS=ACTIVE)
         歸檔完成後，STATUS=INACTIVE，可被覆蓋

3. 關鍵狀態轉換

四、 Checkpoint (檢查點)：恢復時間目標 (RTO) 的控制桿

1. 核心目的：縮短實例恢復時間

實例崩潰恢復需從「最後一次完成的檢查點 SCN」開始前滾 Redo。**檢查點越頻繁/越完整，恢復讀取的 Redo 量越少，恢復越快。**

2. 檢查點類型

3. FAST_START_MTTR_TARGET：自動調優恢復時間

• 設置目標實例恢復時間 (秒)，如 `ALTER SYSTEM SET fast_start_mttr_target=300;` (5 分鐘)。
• Oracle 自動調整增量檢查點頻率/強度、DBWR 寫入速率以滿足目標。
• 查看建議：`SELECT * FROM v$mttr_target_advice;`

五、 歸檔模式下的 Redo 生命週期延伸

Online Redo Log (循環覆蓋)
      │ ARCn 複製
      ▼
Archived Redo Log (永久保留，至備份/刪除策略過期)
      │ RMAN BACKUP ARCHIVELOG / Data Guard 傳輸
      ▼
異地存儲 / 備庫
      │ RMAN DELETE ARCHIVELOG BACKED UP 2 TIMES TO SBT / 
      │   DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7' /
      │   Flash Recovery Area 自動過期清理
      ▼
徹底刪除

六、 故障恢復兩階段：前滾與回滾

1. 前滾 : 從最後檢查點 SCN 讀取 Redo (Online + Archived)，重做所有變更 (含已提交與未提交)，將數據庫推至崩潰時刻一致狀態。
2. 回滾 : 針對崩潰時未提交事務，利用 Undo 數據撤銷其變更，釋放鎖資源。

關鍵點： 僅前滾階段需讀取 Redo，**檢查點決定前滾起點**，直接影響 RTO。

七、 運維關鍵指標監控