根本原因是standby_file_management=auto时，oracle不解析主库的alter database move datafile操作，因其不生成可传播的redo日志，仅监听create/add/drop及rename file两类变更，导致备库路径未更新而生成unnamed占位符。
备库无法识别主库在线重命名的数据文件，根本原因是 STANDBY_FILE_MANAGEMENT 参数为 AUTO 时，Oracle 不会解析或应用主库发出的 ALTER DATABASE MOVE DATAFILE 操作——它被当成“非归档日志可传播”的 DDL，直接跳过。
STANDBY_FILE_MANAGEMENT=AUTO 为何屏蔽 MOVE DATAFILE
Oracle 12c 的在线重命名（MOVE DATAFILE）本质是：先在 OS 层复制文件、再原子性更新控制文件和数据字典。这个过程不生成传统 redo 日志条目，而是由后台进程通过内部消息机制协调。但 DG 的 STANDBY_FILE_MANAGEMENT=AUTO 只监听两类变更：CREATE/ADD/DROP DATAFILE 和 ALTER DATABASE RENAME FILE（旧式离线重命名）。它对 MOVE 操作无感知。
- 查看当前设置：
SHOW PARAMETER STANDBY_FILE_MANAGEMENT，若返回AUTO，就已埋下隐患 - 主库执行
ALTER DATABASE MOVE DATAFILE '/old.dbf' TO '/new.dbf'后，备库v$datafile中路径仍为/old.dbf，且文件物理上未移动 - 后续主库往该文件写入数据，备库 MRP 进程尝试应用时会报
ORA-01111（名称未知）或ORA-01157（无法标识/锁定数据文件）
备库出现 UNNAMED 文件和 ORA-01111 的典型链路
当主库完成 MOVE、备库又恰好在此期间应用了包含该文件变更的归档日志（比如日志里带了新路径的 checkpoint），而备库本地没有对应文件时，Oracle 会创建占位符：
- 在
v$datafile中看到类似UNNAMED00245的记录 - alert 日志出现：
File #245 added to control file as 'UNNAMED00245'. Originally created as: '/new.dbf' - MRP 进程卡住，报错：
ORA-01111: name for data file 245 is unknown - rename to correct name - 此时不能直接
ALTER DATABASE RENAME FILE，因为控制文件里该文件状态已是RECOVER，需先处理恢复上下文
正确修复流程：从 cancel 到 online 的四步闭环
核心思路是：让备库放弃“自动管理幻觉”，手动接管文件路径一致性。所有操作必须在备库 MOUNT 状态下进行：
- 停掉实时应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL - 确认异常文件编号：
SELECT FILE#, NAME FROM V$DATAFILE WHERE NAME LIKE '%UNNAMED%' - 强制重命名（绕过 AUTO 限制）：
ALTER DATABASE RENAME FILE '/u01/oradata/UNNAMED00245' TO '/u01/oradata/new.dbf'—— 注意路径必须与主库完全一致，包括大小写和斜杠方向 - 重启应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
如果 RENAME 报 ORA-01511，说明 STANDBY_FILE_MANAGEMENT 仍为 AUTO，需先临时改为 MANUAL：ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL SCOPE=MEMORY，操作完再改回（但不建议长期设为 MANUAL）。
预防比修复更重要：主库重命名前必做三件事
在线重命名不是“主库一执行，备库自动跟”，它需要 DBA 主动协同：
- 主库执行前，在备库先检查目标路径是否存在、权限是否可写：
!ls -l /u01/oradata/new.dbf，不存在则提前touch或建空文件（避免 MRP 创建 UNNAMED） - 主库重命名后，立刻在备库运行：
SELECT FILE#, NAME, STATUS FROM V$DATAFILE WHERE FILE# = &file_num，验证路径是否已更新（部分版本会在下次日志切换后同步路径） - 若使用 ASM，确保主备两端 diskgroup 名称、挂载状态、权限完全一致；
+DG_DATA在备库不存在会导致ORA-15001，进而触发 UNNAMED
真正容易被忽略的是：12c 的 MOVE DATAFILE 在 DG 环境中不是“透明操作”，它要求主备存储路径语义一致，且备库不能依赖 AUTO 模式来兜底——一旦路径不匹配，UNNAMED 就是必然结果，不是偶发故障。
