RMAN不存在“永久增量备份”，实际只有累积增量（CUMULATIVE）配合合理保留策略；其依赖有效的LEVEL 0基础备份，一旦LEVEL 0过期或被删，增量链即失效，且不支持合成全备。
RMAN 没有“永久增量备份”这个功能，所谓“永久增量”是误传或对 BACKUP INCREMENTAL LEVEL 1 CUMULATIVE 的误解。真实可用的是“累积增量”（cumulative）+ 合理保留策略，而非无限追加。
为什么不存在“永久增量备份”
RMAN 的增量备份必须依赖一个有效的 LEVEL 0 基础备份。所有 LEVEL 1（无论 DIFFERENTIAL 还是 CUMULATIVE）都指向最近的、未过期的 LEVEL 0。一旦该 LEVEL 0 被 DELETE OBSOLETE 或超出保留策略被清理，后续所有基于它的增量备份就失去恢复能力——RMAN 不会自动重建或迁移增量链。
常见误解来源：
- 把“启用块更改跟踪（
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING）”当成“永久增量”，其实它只是加速增量扫描，不改变备份层级依赖关系 - 把“长期保留
LEVEL 0+ 每日CUMULATIVE”当成“永久”，但只要LEVEL 0被删，链就断 - 混淆了 RMAN 和某些第三方备份工具（如 Veritas、Commvault）的合成全备（synthetic full）能力，RMAN 原生不支持合成
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE 的实际行为
它每次备份自最近一次 LEVEL 0 以来所有变更的数据块，不是自上次 LEVEL 1。这意味着：
- 恢复时只需：一个
LEVEL 0+ 最新一个CUMULATIVE备份，比DIFFERENTIAL少应用中间备份 - 但备份体积随时间线性增长——第 7 天的
CUMULATIVE几乎等于全库大小，失去增量本意 - 不能跳过旧
CUMULATIVE：RMAN 不会自动合并或压缩历史增量，只按需调用
示例命令：
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE FORMAT '/bkp/db_%U';
注意：CUMULATIVE 不是默认模式，必须显式写出；省略则为 DIFFERENTIAL。
真正可持续的增量策略：滚动 LEVEL 0 + DIFFERENTIAL
生产环境更推荐差异增量（DIFFERENTIAL）配合定期刷新 LEVEL 0，原因很实际：
-
LEVEL 0每月/每季度重做一次，避免单点失效风险 -
LEVEL 1 DIFFERENTIAL每日执行，体积小、速度快 - 恢复窗口可控：比如保留最近 2 个
LEVEL 0+ 所有其后的LEVEL 1，用CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS - 必须同步控制文件记录时效：
ALTER SYSTEM SET CONTROL_FILE_RECORD_KEEP_TIME = 60;（尤其不用 catalog 时）
关键操作顺序不能错：
- 先做
LEVEL 0（含INCLUDE CURRENT CONTROLFILE或确保AUTOBACKUP ON） - 再做
LEVEL 1 DIFFERENTIAL，RMAN 自动识别最近LEVEL 0 - 恢复前务必
CROSSCHECK BACKUP，防止因控制文件记录过期导致找不到备份片
容易被忽略的三个硬限制
这些不是配置问题，而是 RMAN 架构决定的刚性约束：
-
LEVEL 0必须存在且未过期——没有“无基底增量”，RMAN 不允许只备份增量而不关联LEVEL 0 - 块更改跟踪文件（
change tracking file）最大仅支持 10GB，超限后增量性能反而下降，需监控V$BLOCK_CHANGE_TRACKING - 使用控制文件存储元数据时，
CONTROL_FILE_RECORD_KEEP_TIME低于备份保留周期，会导致 RMAN “看不见”旧备份，哪怕物理文件还在磁盘上
所以所谓“永久”，其实是靠人工维护 LEVEL 0 生命周期 + 元数据持久化（强烈建议部署 recovery catalog），而不是靠某条命令一劳永逸。
