里程碑時間軸
| 版本 | 關鍵特性 | 技術突破 | 殘留痛點 |
|---|
| 8.0 |
RMAN 首發 |
首次實現真正增量備份：僅備份修改過的數據塊，而非整表重寫 (Exp 增量導出) |
每次增量備份需全量掃描數據文件尋找變更塊，大庫耗時接近全備 |
| 9i/10gR1 |
RMAN 持續增強 |
備份集壓縮、並行備份、磁帶管理 API |
掃描開銷未本質解決 |
| 10gR2 |
塊變更跟蹤 (Block Change Tracking, BCT) |
後台進程 (CTWR) 實時記錄變更塊 ID 至專用文件，增量備份直接讀取 BCT 文件定位變更塊，跳過全量掃描 |
首次啟用仍需一次全量掃描建立基線；CTWR 進程佔用少量 CPU/IO |
| 11g+ |
BCT 成熟化 |
多實例 (RAC) 共享 BCT 文件、快速增量備份、恢復窗口優化 |
極高寫入負載下 CTWR 可能成為瓶頸 |
BCT 架構原理
- 啟用：
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/path/rman_bct.f'; (啟用 OMF 可省略路徑)。
- 文件特徵：初始 10MB，按 10MB 自動擴展；記錄每個數據文件的「變更塊位圖」。
- 寫入路徑：DBWR 寫入數據塊時，同步標記內存位圖；CTWR 定期刷盤至 BCT 文件 (非同步，不阻塞用戶事務)。
- 備份路徑：RMAN 讀取 BCT 文件 → 直接定位變更塊 → 僅讀取/備份這些塊 → 備份集體積與時間大幅縮減。
啟用 BCT 完整操作流
-- 1. 確認數據庫處於 OPEN 或 MOUNT 狀態
SELECT status FROM v$instance;
-- 2. 啟用 BCT (建議放在快速存儲、獨立磁盤組)
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '+FRA/ORCL/BCT/change_tracking.f' REUSE;
-- 3. 驗證狀態
SELECT status, filename, bytes/1024/1024 AS size_mb
FROM v$block_change_tracking;
-- 4. 首次增量備份 (含基線掃描)
RUN {
BACKUP INCREMENTAL LEVEL 1 DATABASE;
}
-- 5. 後續增量備份 (極速)
RUN {
BACKUP INCREMENTAL LEVEL 1 DATABASE;
}
性能量化預期 (典型 OLTP, 10TB 數據庫)
| 指標 | 無 BCT | 啟用 BCT | 提升 |
|---|
| 增量備份掃描量 | 10 TB (全量掃描) | ~50-200 GB (實際變更量) | 50x - 200x |
| 備份耗時 | 4-6 小時 | 15-40 分鐘 | 10x+ |
| 備份集大小 | ~2-3 TB (壓縮後) | ~50-200 GB | 10x+ |
| CTWR CPU 佔用 | N/A | < 1% 單核 | 可忽略 |
權衡與避坑指南
- 不要在以下場景啟用：
- 純只讀/極少寫入數據庫 (收益不抵管理成本)
- 存儲設備不支持快速隨機寫 (CTWR 刷盤延遲大)
- 極端寫入熱點 (如高頻批量載入) 導致 CTWR 追不上，反而拖慢检查點
- 監控關鍵指標：
V$BLOCK_CHANGE_TRACKING 中 BYTES/DIRTY_BYTES、V$SESSION_WAIT 事件 block change tracking。
- 禁用操作：
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; 文件自動刪除 (OMF) 或手動清理。
總結
RMAN 8.0 確立了增量備份「只備份變更」的邏輯，10g BCT 解決了「如何快速找到變更」的物理難題。兩者結合，構成了現代 Oracle 大規模數據庫備份策略的基石：**Level 0 週全備 + Level 1 日增備 (BCT 加速) + 歸檔日志連續備份**，可將 RPO 壓縮至分鐘級、RTO 控制在業務可接受窗口內。
