背景痛點
Oracle 8i 引入 RMAN 實現真正增量備份,僅備份變更區塊。但 10g 前,增量備份需掃描整個資料檔判斷變更區塊,大型資料庫雖節省空間,耗時卻接近完整備份。
區塊變更追蹤技術
運作原理
- 後台進程 CTWR 即時將變更區塊資訊寫入獨立追蹤檔案
- 首次增量備份仍需完整掃描建立基準
- 後續備份直接讀取追蹤檔,定位變更區塊,避免全盤掃描
啟用方法
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/u01/app/oracle/oradata/ORCL/change_track.f';
- 若啟用 OMF(
DB_CREATE_FILE_DEST),USING FILE 子句可省略
- 追蹤檔初始 10MB,每次擴增 10MB
- 檔案位置建議放在快速儲存裝置
停用方法
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
效能影響與建議
| 面向 | 影響 | 建議 |
| CPU/IO | CTWR 進程持續寫入追蹤檔,略增系統負載 | 僅在使用 RMAN 增量備份時啟用 |
| 備份速度 | 後續增量備份大幅加速(避免全盤掃描) | 大型資料庫、頻繁增量備份環境強烈建議啟用 |
| 空間 | 追蹤檔佔用額外空間(通常極小) | 監控追蹤檔大小,確保磁碟空間充足 |
驗證啟用狀態
SELECT status, filename, bytes
FROM v$block_change_tracking;
STATUS FILENAME BYTES
---------- ------------------------------------------ -------
ENABLED /u01/app/oracle/oradata/ORCL/change_track.f 10485760
適用場景總結
- ✅ 大型資料庫(TB 級)每日增量備份
- ✅ 備份視窗緊迫,需縮短增量備份時間
- ✅ 使用 RMAN 累積/差異增量備份策略
- ❌ 僅做完整備份的環境
- ❌ 極度敏感於 CPU/IO 額外開銷的核心業務系統
- 上一篇文章: 解決 ORA-01991 錯誤:重建 Oracle 密碼檔案實戰
- 下一篇文章: Oracle imp 導入備份資料:字元集不匹配解決實戰
Copyright ©
程式碼之家 All Rights Reserved