RMAN没有“增量合并备份”概念，实际是通过CUMULATIVE策略或INCREMENTAL UPDATE实现类似效果：前者使LEVEL 1备份包含自最近LEVEL 0以来全部变更，后者将LEVEL 1增量应用到映像副本上更新其状态。
RECOVER 命令自动应用多个增量备份，或借助 BACKUP INCREMENTAL LEVEL 0 + CUMULATIVE 策略间接达成类似效果。
为什么不能直接“合并”增量备份文件？
RMAN 的增量备份（LEVEL 1）本质是记录块级变化的差异集，不是可编辑的文件；它必须依赖 LEVEL 0 作为基线才能被识别和应用。RMAN 不提供类似 cat 或 dd 那样的物理合并命令，强行拼接备份集会导致校验失败、ORA-19566 或恢复中断。
替代方案：用 CUMULATIVE 实现逻辑“合并”效果
累积增量（INCREMENTAL LEVEL 1 CUMULATIVE）每次备份都包含自最近 LEVEL 0 以来所有变更块，相当于把中间所有 LEVEL 1 DIFFERENTIAL 的内容“收拢”进单个备份集。这样恢复时只需应用一个 LEVEL 1 CUMULATIVE，而非多个 DIFFERENTIAL。
-
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;—— 每次都覆盖上次 CUMULATIVE，不依赖前序 LEVEL 1 - 必须有有效的
LEVEL 0（哪怕已过期，只要未被DELETE OBSOLETE清除） - 备份体积比 DIFFERENTIAL 大，但恢复步骤更少、更可靠
- 适合每日执行、且对恢复时间目标（RTO）敏感的场景
真正能“合并”的操作：增量更新备份（INCREMENTAL UPDATE）
这是唯一接近“合并”语义的 RMAN 功能：它把 LEVEL 1 增量直接应用到现有数据文件副本（IMAGE COPY）上，让副本“向前滚动”，等效于生成一个新的、更新过的全量副本。
- 先创建映像副本：
BACKUP AS COPY DATABASE FORMAT '/backup/copy/%U'; - 再执行增量更新：
RECOVER COPY OF DATABASE WITH TAG 'my_copy'; - 该命令会查找带相同
TAG的LEVEL 1增量备份，并将其变更应用到副本上 - 结果：副本变成“截至增量备份时间点”的一致镜像，后续可用
SWITCH TO COPY快速切换 - 注意：
RECOVER COPY不修改原数据库，只更新副本；且要求副本和增量备份都在同一 RMAN 目录/控制文件中可见
容易被忽略的关键点
块更改跟踪（BCT）开启与否，直接影响 LEVEL 1 扫描效率，但不影响 CUMULATIVE 或 INCREMENTAL UPDATE 的逻辑行为；而 CONTROL_FILE_RECORD_KEEP_TIME 若设得太小（如默认 7 天），可能导致旧 LEVEL 0 元数据被覆盖，使后续 CUMULATIVE 或 RECOVER COPY 找不到基线——这时即使物理备份文件还在，RMAN 也报 ORA-19624 或跳过该备份。务必确认该参数 ≥ 最长保留周期，或启用恢复目录（catalog）规避此限制。
