oracle 19c 不支持对 backup as copy 直接执行 level 1 增量备份，必须用 recover copy + backup incremental for recover of copy 组合实现增量合并；因 image copy 是物理全拷贝、无增量元数据，rman 仅对 backupset 支持增量逻辑，指定 level 1 会报 rman-06022 错误。
rman 不支持对 backup as copy 直接加 level 1，所谓“增量合并备份”必须用 recover copy + backup incremental for recover of copy 组合实现——这是唯一合法路径。
为什么 BACKUP AS COPY INCREMENTAL LEVEL 1 一定报错 RMAN-06022
Oracle 19c 明确禁止在 BACKUP AS COPY 语句中指定 LEVEL 1。执行时直接失败，错误信息就是：RMAN-06022: invalid level specified for image copy: 1。
根本原因在于：image copy 是裸文件级拷贝（类似 cp），不带任何增量元数据；而 RMAN 的增量逻辑只作用于 backupset（含块索引、压缩、校验等结构）。所谓“合并”，其实是把 backupset 里的变更块反向应用到已有 image copy 上，不是在 copy 上做增量备份。
- 首次运行
RECOVER COPY时若无对应 tag 的镜像，RMAN 自动创建一个LEVEL 0 image copy（即 base copy） - 后续每次运行，RMAN 先查找最新匹配 tag 的
LEVEL 1 backupset，再把它的变更块写入 base copy 对应数据文件 - 整个过程不依赖归档日志，纯物理块级更新，也不需要
RESTORE
标准脚本必须用 RUN 块包裹且顺序不可颠倒
以下结构是 Oracle 19c 增量合并备份的强制语法模板，缺一不可：
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 -
RECOVER COPY必须在BACKUP INCREMENTAL之前，顺序反了会报错或跳过更新 - 首次运行：生成 base copy（
LEVEL 0 image copy）+ 第一个LEVEL 1 backupset - 第二次运行：先用第一个
LEVEL 1更新 base copy，再生成第二个LEVEL 1
base copy 文件名由 RMAN 自动生成（如 /u01/backup/DBNAME/data_D-DBNAME_I-1234567890_FNO1.bak），无法自定义路径或格式。
增量合并备份依赖 ARCHIVELOG 模式但不依赖归档日志回滚
虽然 RECOVER COPY 不读取归档日志，但它要求数据库处于 ARCHIVELOG 模式——否则 RMAN 会拒绝执行，报错类似 RMAN-06054: media recovery requesting unknown log 或直接跳过增量应用。
- 验证方式：
ARCHIVE LOG LIST输出必须含Database log mode: Archive Mode - 切换步骤需重启：
SHUTDOWN IMMEDIATE→STARTUP MOUNT→ALTER DATABASE ARCHIVELOG→ALTER DATABASE OPEN - 归档路径建议显式设置：
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog' SCOPE=SPFILE
注意：即使设置了归档路径，增量合并本身也不会写入或消耗归档日志；它只依赖已存在的 LEVEL 1 backupset 中记录的变更块地址和内容。
容易被忽略的三个实操细节
实际部署时，这三个点最容易导致“看似成功、实则没更新”：
- 第一次运行后，检查输出里是否有
no copy of datafile found to recover—— 这是正常现象，说明 base copy 正在创建；但第二次运行仍出现该提示，说明 tag 不一致或前次未真正完成 -
LIST COPY OF DATABASE和LIST BACKUP OF DATABASE要分开查：前者看 base copy 是否存在且 SCN 更新，后者确认LEVEL 1 backupset是否生成并带正确 tag - 如果 base copy 所在磁盘空间不足，
RECOVER COPY会静默失败（不报错但不写入），只留下旧 copy；务必监控目标路径剩余空间，而非仅看 RMAN 日志中的 “completed” 字样
