oracle 19c rman 不支持自动合成备份，所谓“自动合并”是误解；真正实现等效全备需手动执行 backup as copy、增量备份及 recover copy 命令链。
Oracle 19c RMAN 不支持自动合成备份（synthetic backup）
RMAN 本身没有 SYNTHETIC 或 AUTOMERGE 模式，所谓“自动合并”是常见误解。19c 的 BACKUP INCREMENTAL LEVEL 1 只生成增量备份集，不会自动把 Level 0 和后续 Level 1 合成新全备——它仍需在恢复时按顺序应用，RMAN 不会物理重写或覆盖原有 Level 0。
想实现等效“自动合并”，必须手动触发 RECOVER COPY
真正能生成一个“逻辑上等价于新全备”的备份副本，靠的是 RECOVER COPY 命令，它把已有的镜像复制（BACKUP AS COPY）和增量备份合并成更新后的数据文件副本。这是唯一被 Oracle 官方支持的“合成”路径：
- 先用
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE创建基础镜像（不是备份集） - 后续用
BACKUP INCREMENTAL LEVEL 1生成增量备份集 - 再执行
RECOVER COPY OF DATABASE WITH TAG 'L0_COPY'—— 这步才真正把增量内容“打进去”，更新镜像副本 - 最后
SWITCH DATABASE TO COPY可让实例直接指向新副本（用于快速切换/克隆）
注意：RECOVER COPY 不修改原始 Level 0 备份集，只更新你指定的 AS COPY 文件；且必须确保控制文件中记录了所有相关增量备份（否则报错 ORA-19625）。
REPORT OBSOLETE 和 DELETE OBSOLETE 不会触发合并
配置了 CONFIGURE RETENTION POLICY 后运行 DELETE OBSOLETE，只会删掉被策略判定为过期的备份集，绝不会把 Level 0 和 Level 1 合并成一个新文件。有人误以为“删旧备份=自动整理”，其实只是清理，不改变备份结构。
典型陷阱：
- 没做
BACKUP AS COPY，直接对备份集跑RECOVER COPY→ 报错no copy of datafile found - 增量备份后没做
CROSSCHECK BACKUP，控制文件丢失增量记录 →RECOVER COPY找不到可应用的增量片 - 把
BACKUP DATABASE PLUS ARCHIVELOG当作 Level 0 使用 → 它是备份集，不能用于RECOVER COPY
生产环境更推荐用 BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY
这是 19c 明确优化过的增量流：它专为配合 AS COPY 场景设计，生成的 Level 1 增量只适用于恢复镜像副本，不参与常规数据库恢复链。命令简洁、校验严格、不易误用：
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'PHYSICAL_STANDBY' DATABASE;
}
关键点：
- 必须已有带相同
TAG的BACKUP AS COPY - 生成的增量备份自带元数据约束，RMAN 不会把它错用于普通
RECOVER DATABASE - 比通用 Level 1 更安全，避免人为混用导致恢复失败
真正的“自动”只存在于调度脚本里：你得自己把 BACKUP AS COPY、BACKUP INCREMENTAL ... FOR RECOVER OF COPY、RECOVER COPY 串成定时任务，RMAN 不会替你决定何时合并。
