oracle 19c 不支持对 backup as copy 直接执行 level 1 增量备份，因 image copy 是物理全拷贝、无增量元数据，rman 仅对 backupset 支持增量逻辑；必须用 recover copy + backup incremental for recover of copy 组合实现增量合并。
oracle 19c 中不能直接对 backup as copy 执行 level 1 增量备份，必须用 recover copy + backup incremental ... for recover of copy 组合实现“增量合并”效果。
为什么 BACKUP AS COPY INCREMENTAL LEVEL 1 会报错 RMAN-06022
因为 RMAN 明确禁止对 image copy 类型备份指定 LEVEL 1。执行时会直接失败：
RMAN-06022: invalid level specified for image copy: 1
根本原因：image copy 是物理文件的完整拷贝（类似操作系统 cp），不带增量元数据；RMAN 的增量逻辑只作用于 backupset（压缩/加密/块级索引格式）。所谓“增量合并备份”，本质是把增量 backupset 的变更块“回滚应用”到已有 image copy 上，从而更新它。
RECOVER COPY OF DATABASE 的真实作用
这个命令不是恢复数据库，而是“把已有的增量备份（LEVEL 1）打补丁到同 tag 的 image copy 上”。关键点：
- 首次运行时，若无对应 tag 的 image copy，RMAN 自动先创建一个
LEVEL 0image copy（即 base copy） - 后续每次运行，RMAN 查找最新可用的
LEVEL 1backupset（匹配 tag），提取变更块，逐个写入 base copy 对应的数据文件 - 执行完后，base copy 的 SCN 和数据状态等价于该
LEVEL 1备份所覆盖的时间点 - 不需要手动
RESTORE，也不依赖归档日志——这是纯物理块级更新
标准脚本写法与 tag 管理要点
必须用 RUN 块包裹，且 RECOVER COPY 必须在 BACKUP INCREMENTAL ... FOR RECOVER OF COPY 之前（顺序不能反）：
RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE;
}
注意事项：
-
WITH TAG 'incr_update'必须完全一致，大小写敏感，且所有相关命令共用同一 tag - 首次运行会生成 base copy（
LEVEL 0image copy）和第一个LEVEL 1backupset - 第二次运行时，RMAN 先用第一个
LEVEL 1更新 base copy，再生成第二个LEVEL 1backupset - base copy 文件名由 RMAN 自动生成（如
/u01/backup/DBNAME/data_D-DBNAME_I-1234567890_FNO1.bak），不可自定义路径或格式
恢复时怎么用这个增量合并备份
它不改变标准恢复流程，但极大缩短恢复时间：
- 启动到
MOUNT状态后，直接RESTORE DATABASE—— RMAN 会自动选中最新更新过的 image copy（即“滚动前进了”的 base copy） - 接着执行
RECOVER DATABASE—— 此时只需应用从该 image copy SCN 到故障点之间的归档日志，而非从最老全备开始 - 如果 base copy 是昨天更新的，那最多只回放 24 小时内的归档，而不是一周的
- 注意：
RESTORE不会覆盖原 datafile，而是先复制到目标位置；确保DB_RECOVERY_FILE_DEST或指定SET NEWNAME有足够空间
真正容易被忽略的是 tag 的生命周期管理：一旦用了某个 tag 启动增量合并策略，就不能随意删掉对应 backupset 或 base copy，否则后续 RECOVER COPY 会找不到输入源而中断。建议定期用 LIST COPY OF DATABASE 和 LIST BACKUP BY FILE 核对一致性。
