Oracle 19c 不支持 BACKUP AS COPY INCREMENTAL LEVEL 1，因镜像副本无块变更元数据，RMAN-06022 是设计限制；唯一可行路径是 RECOVER COPY 结合 backupset 增量更新镜像副本。
oracle 19c 不支持对 backup as copy 直接执行 level 1 增量备份，所以“镜像副本 + 增量更新”不是推荐选项，而是唯一能实现“类增量合并”的物理备份路径。
为什么 BACKUP AS COPY INCREMENTAL LEVEL 1 会报 RMAN-06022
这个错误不是配置问题，是 RMAN 的硬性限制：image copy 是裸文件拷贝（类似 cp），不带块变更元数据；而增量逻辑只作用于 backupset（含块索引、压缩、校验等结构）。RMAN 明确禁止在 BACKUP AS COPY 后指定 LEVEL 1，一执行就失败。
-
RMAN-06022: invalid level specified for image copy: 1是设计使然，不是 bug - 想用镜像副本做“接近全备恢复速度”的备份，就必须绕过直接增量，改用
RECOVER COPY回滚应用 - backupset 可以做增量，但恢复时要串联多个备份集；image copy 更新后是单个物理文件，恢复免解析链路
RECOVER COPY OF DATABASE 真实干了什么
它不是在恢复数据库，是在“打补丁”——把已有的 LEVEL 1 backupset 中的变更块，原样写入同 TAG 的 image copy 对应数据文件位置。
- 首次运行：若无匹配
TAG的 image copy，RMAN 自动创建一个LEVEL 0镜像副本（base copy） - 后续运行：
RECOVER COPY先找最新可用的LEVEL 1backupset（按TAG匹配），提取变更块，覆盖 base copy 文件 - 执行完后，该 image copy 的 SCN 和数据状态 = 对应
LEVEL 1备份所覆盖的时间点 - 全程不依赖归档日志，也不需要
RESTORE步骤，纯物理块级更新
标准脚本里 WITH TAG 必须严格一致
TAG 是整个机制的锚点，大小写敏感，且所有命令必须共用同一值，否则 RMAN 找不到关联对象。
- 脚本顺序不能颠倒：
RECOVER COPY必须在BACKUP INCREMENTAL ... FOR RECOVER OF COPY之前 - 首次运行时，
RECOVER COPY无事可做（无 base copy），但BACKUP ... FOR RECOVER OF COPY会生成 base copy + 第一个LEVEL 1backupset - 第二次运行，
RECOVER COPY把第一个LEVEL 1应用到 base copy，再由后续语句生成第二个LEVEL 1 - base copy 路径不可控，由 RMAN 自动生成（如
/u01/backup/DBNAME/data_D-DBNAME_I-1234567890_FNO1.bak），不能指定格式或重命名
真正容易被忽略的是：这种策略下，base copy 的“新鲜度”完全取决于最后一次 RECOVER COPY 是否成功执行——如果某次失败，后续的增量 backupset 还在，但 base copy 已滞后，且 V$BACKUP_COPY_SUMMARY 的 MAX_COMPLETION_TIME 不会自动更新，得靠人工核对 MAX_END_SCN 和最近一次 LEVEL 1 的 SCN 是否对齐。
