差异增量备份默认执行，恢复需按序应用所有中间备份，链断裂易致rman-06059错误；累积增量需显式加cumulative，恢复仅需最新累积备份加level 0，但依赖level 0存在。
差异增量备份默认但恢复链长
执行 BACKUP INCREMENTAL LEVEL 1 DATABASE 就是差异增量，RMAN 会找最近一次 **同级或更低级别** 的备份（比如上一个 LEVEL 1 或 LEVEL 0）作为基准，只备份那之后变化的块。它速度快、占空间小，但恢复时得按时间顺序逐个应用所有中间增量备份——比如你有周日 LEVEL 0、周一 LEVEL 1、周二 LEVEL 1、周三 LEVEL 1，恢复就得把这四个备份全跑一遍。
常见错误现象：RMAN-06059: expected archived log not found 或恢复卡在某个 APPLY ARCHIVELOG 步骤，往往是因为某次差异备份缺失，导致链断裂。
- 适用场景：备份窗口极短、存储紧张、能接受较长恢复时间（如开发/测试库）
- 参数差异：不加
CUMULATIVE就是差异模式，无需额外关键字 - 性能影响：每次备份只读取少量变更块，I/O 压力低，但依赖块更改跟踪（BCT）文件有效；若 BCT 损坏或禁用，RMAN 会退回到全扫描，耗时剧增
累积增量备份需显式声明但恢复更快
必须写明 CUMULATIVE：执行 BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE。它只认 LEVEL 0 为唯一基准，每次备份都包含自上次 LEVEL 0 以来所有变化的块。这意味着周二和周三的两次累积备份内容高度重叠，备份体积大、耗时长，但恢复时只要最新一次累积备份 + LEVEL 0 就够了。
容易踩的坑：CUMULATIVE 不是默认行为，漏写就变成差异备份，策略预期直接失效；另外，如果 LEVEL 0 被删除或过期，所有累积备份立刻失去意义——它们都依赖同一个基线。
- 适用场景：生产库要求 RTO 极短（比如
- 兼容性注意：Oracle 10g+ 支持，但 9i 不支持该语法，会报错
ORA-19602: backup of datafile in NOARCHIVELOG mode（即使实际是归档模式） - 存储代价：同一周期内，累积备份总大小通常比差异备份多出 2–3 倍，尤其当数据变化率稳定时
块更改跟踪（BCT）对两者都关键
无论选差异还是累积，ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 都不是可选项——它是让增量备份真正高效的前提。没开 BCT，RMAN 每次都得全库扫描数据块头获取 SCN，1TB 库可能要 2 小时；开了之后，只读 BCT 文件（通常几 MB），10 分钟内完成。
真实问题：BCT 文件本身单点故障。它默认写在 +DATA ASM 磁盘组，若该磁盘组不可用，所有增量备份立即失败，报错 ORA-19755: could not open change tracking file。
- 建议路径：用
USING FILE '/u01/oradata/bct.f'指向独立、高可用的文件系统，避免和数据文件共盘 - 监控命令：
SELECT status, filename, bytes FROM v$block_change_tracking，确保STATUS是ENABLED - 别忽略
AUTOEXTEND ON：BCT 文件会随数据库增长而膨胀，手动管理极易满盘
LEVEL 0 备份不是“全备”，而是基线锚点
BACKUP INCREMENTAL LEVEL 0 DATABASE 和 BACKUP DATABASE 物理内容一样，但逻辑完全不同：前者可作为后续所有 LEVEL 1 的父备份，后者不能。误用全备当基线，会导致后续所有增量备份无法用于恢复，报错 RMAN-06023: no backup or copy of datafile exists。
最常被忽略的细节：0 级备份也分差异和累积。虽然极少用，但语法上支持 BACKUP INCREMENTAL LEVEL 0 CUMULATIVE DATABASE——它没有实际意义，因为 0 级本身就是全量，但 RMAN 允许，且会静默忽略 CUMULATIVE 关键字。
- 强制策略：每周固定时间跑一次
LEVEL 0，并用KEEP UNTIL TIME 'SYSDATE+30'显式保留，防止被自动清理 - 验证命令：
LIST BACKUP OF DATABASE SUMMARY，确认输出里INCREMENTAL LEVEL列明确标出0，而非空值 - 别指望压缩替代：即使开启
AS COMPRESSED BACKUPSET，0 级仍是最大备份，必须预留足够空间
