RMAN-06094 报错本质是控制文件中记录的数据文件路径与实际磁盘或ASM上文件路径不匹配，需通过catalog datafilecopy和switch datafile to copy修复路径映射，而非执行restore。
RMAN-06094 报错本质是数据文件路径不一致
这个错误不是“缺备份”，而是控制文件里记录的 datafile 路径和实际磁盘（或 ASM）上存在的文件不匹配。RMAN 在 recover database 阶段发现某个 datafile 的物理位置无法定位，就直接报 RMAN-06094: datafile X must be restored —— 但你执行 restore database 往往会失败或创建空文件，因为根本没对应副本。
常见触发场景包括：
- ADG 备库从主库拉取了 OMF 自动生成的文件名（如
system.275.1043745635），但 ASM 转换失败，v$datafile里显示MUST_RENAME_THIS_DATAFILE - 主库新增了数据文件，备库没同步控制文件，也没做对应
backup current controlfile for standby - 增量恢复时，主库做了
add datafile，但增量备份没包含该文件，或备库没 catalog 对应 copy - 手工 restore 后忘了
switch，控制文件仍指向旧路径
先确认哪些 datafile 出问题
别急着 restore，先查清楚范围。RMAN 只报第一个出错的 file#，但往往不止一个：
select file#, name from v$datafile where name like '%MUST_RENAME_THIS_DATAFILE%';
select file#, name from v$datafile_header where name is null;
如果结果非空，说明这些 file# 对应的数据文件头路径为空，控制文件没认到真实文件 —— 这就是 RMAN-06094 的根源。
再看 ASM 实际存在哪些文件：
ASMCMD> ls -l +DATA/your_db_name/datafile/
对比 v$datafile 中的逻辑名和 ASM 里的物理名，找出能映射上的真实路径。
用 catalog + switch 修复路径映射
核心动作不是 restore，而是让 RMAN 控制文件“认出”已存在的文件副本。步骤必须严格按顺序：
- 在 RMAN 中运行
list copy of database;，确认对应file#的datafile copy存在且状态为AVAILABLE - 若 copy 路径不在 RMAN repository 里，手动 catalog：
catalog datafilecopy '+DATA/.../system.xxx.yyy';（路径必须完整、准确） - 执行
switch datafile <file_number> to copy;</file_number>（例如switch datafile 1 to copy;）—— 这步更新控制文件中该file#的name字段 - 验证：
report schema;看输出里该 datafile 的Datafile Name是否已变成真实 ASM 路径，且FileSize(MB)非零
注意：不能用 switch database to copy 批量切换，它要求所有 datafile 都有可用 copy，否则报 RMAN-06571；逐个 switch 更稳妥。
增量恢复后必须同步控制文件
如果是在 ADG 场景下做基于 SCN 的增量恢复，recover database noredo 前漏掉关键一步：主库必须先执行
backup current controlfile for standby format '/tmp/ctl_%U';
然后把生成的控制文件拷到备库，restore controlfile from '/tmp/ctl_...'; 再启动到 mount 状态。否则备库控制文件不知道主库新增的 datafile，RMAN 就找不到目标位置。
另外，OMF 环境下尤其容易踩坑：主库用 OMF 创建的文件名带长数字串（如 .275.1043745635），备库 ASM 可能无法自动解析成合法路径，导致 v$datafile 里硬写 MUST_RENAME_THIS_DATAFILE —— 这时候靠 catalog + switch 是唯一可靠解法，别信“重启实例自动修复”这类说法。
