cumulative 增量备份每日从最近 level0 开始重算变更块，恢复仅需 level0 + 最新 cumulative；必须先有 level0 作唯一基准，误删则后续所有 cumulative 备份失效；区别于 differential，其不依赖中间 level1，但体积更大。
BACKUP INCREMENTAL LEVEL1 CUMULATIVE 是每日增量合并备份的实际落地方案，不是“每天把前一天的增量再备份一遍”，而是每天备份自最近一次 LEVEL0 以来所有变更块 —— 这就是“合并”的本质。
为什么必须先有 LEVEL0 才能做增量合并？
LEVEL0 不是可选步骤，它是 CUMULATIVE 模式的唯一基准点。RMAN 不会向前追溯多个 LEVEL1 备份，只认最近一次 LEVEL0 的 SCN 起点。
- 如果上次
LEVEL0是上周日，那周一到本周一的所有CUMULATIVE备份，都包含从周日到各自执行时刻的所有变化块 - 若误删了
LEVEL0备份集，后续所有CUMULATIVE备份在恢复时将无法使用 —— RMAN 报错ORA-19563: datafile header validation failed - 不建议依赖自动
LEVEL0行为（如执行LEVEL1时发现无LEVEL0就自动补一个），因为自动产生的LEVEL0可能没按预期路径保存或打标签，导致恢复链断裂
LEVEL1 CUMULATIVE 和 LEVEL1 DIFFERENTIAL 的关键区别
两者命令只差一个词，但恢复行为和存储开销差异极大：
-
BACKUP INCREMENTAL LEVEL1 DATABASE→ 默认是DIFFERENTIAL：只备份自上一次任意级别（LEVEL0或LEVEL1）以来的变化块。备份体积小，但恢复时需按时间顺序逐个应用所有中间LEVEL1 -
BACKUP INCREMENTAL LEVEL1 CUMULATIVE DATABASE→ 每次都从最近LEVEL0开始“重算”，所以周二的备份包含周一+周二的变更，周三的包含周一+周二+周三的变更。单次备份体积更大，但恢复只需LEVEL0+ 最新CUMULATIVE即可 - 若业务允许每日恢复窗口 ≤ 30 分钟，优先选
CUMULATIVE；若磁盘空间紧张且能接受多步恢复，选DIFFERENTIAL
如何避免“合并”变成“重复备份”？
很多人以为 CUMULATIVE 就是把前几天的备份文件拷贝一份，其实不是。RMAN 实际扫描的是数据文件块的 SCN，不是备份集内容。
- 确保数据库开启归档模式：
ARCHIVELOG必须启用，否则PLUS ARCHIVELOG会失败，且增量备份无法保证一致性 - 控制文件中 RMAN 元数据不能被覆盖：检查
control_file_record_keep_time参数，若仅用控制文件存元数据（未配恢复目录），该值至少设为备份保留天数 + 3，例如保留 14 天备份，建议设为17 - 不要混用两种增量类型在同一备份周期内：比如周日
LEVEL0，周一用CUMULATIVE，周二又切回DIFFERENTIAL—— RMAN 不报错，但恢复路径会混乱，LIST BACKUP显示的“recovery window”可能失效
每日执行脚本里必须显式指定 FORMAT 和 TAG
生产环境不能依赖默认路径或随机标签，否则归档清理、异地恢复、脚本化验证都会出问题。
- 示例命令：
BACKUP INCREMENTAL LEVEL1 CUMULATIVE DATABASE FORMAT '/backup/incr_cum_%d_%T_%U.bkp' TAG 'DAILY_CUMULATIVE';
%d 是数据库名，%T 是日期（YYYYMMDD），%U 是唯一文件名，三者组合可避免同一天多次执行冲突DELETE OBSOLETE 或 DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'，否则归档日志和旧增量备份会撑爆磁盘LIST BACKUP SUMMARY 里看不到，得用 REPORT NEED BACKUP 配合 RECOVERY WINDOW OF 7 DAYS 才能验证是否真满足 SLA。
