ORA-01111报错本质是备库控制文件中UNNAMED占位符未被替换，需在MOUNT状态下禁用STANDBY_FILE_MANAGEMENT后用CREATE DATAFILE重建真实文件，而非RENAME。
ORA-01111报错说明备库缺真实数据文件
这不是路径写错或权限问题，而是备库根本没生成对应物理文件——unnamed000xx是oracle在standby_file_management=manual或路径转换失败时，为占位而生成的伪文件名。它只存在于控制文件里，磁盘上没有实体，mrp进程一碰到就停。
先确认当前standby_file_management模式
直接查参数值，别猜：
SQL> show parameter standby_file_management
如果返回MANUAL，主库新增文件不会自动同步，这是最常见原因；即使显示AUTO，也可能因DB_FILE_NAME_CONVERT配置不全或备库目标路径空间不足，导致自动创建失败。
- 检查
DB_FILE_NAME_CONVERT是否覆盖主库所有可能的路径前缀，比如主库用/oradata/prod/，备库映射必须精确匹配，不能漏掉子目录层级 - 运行
df -h确认备库目标路径所在文件系统剩余空间，尤其注意ASM磁盘组使用率是否超95% - 查
v$recover_file确认缺失文件号：SELECT file#, error FROM v$recover_file WHERE error LIKE '%FILE%';
手动重建UNNAMED文件要分三步走
不能直接rename，必须用create datafile语句重建，且操作前数据库需处于MOUNT状态（OPEN状态下会报错）。
- 先切到
MANUAL模式：ALTER SYSTEM SET standby_file_management = MANUAL; - 执行重建（路径必须与主库一致或按
DB_FILE_NAME_CONVERT规则映射）：ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00075' AS '/lv_oradata/datafile75.dbf'; - 再切回
AUTO：ALTER SYSTEM SET standby_file_management = AUTO;
注意：AS后面的路径必须真实存在、有写权限，且不能和已有文件重名；重建后文件状态仍是OFFLINE，后续靠MRP应用归档日志恢复内容。
重启MRP前务必验证文件路径一致性
重建完不等于万事大吉，MRP启动时仍会校验路径。主库上查该文件真实路径：SELECT file#, name FROM v$datafile WHERE file# = 75;，确保备库AS指定的路径与之逻辑等价（比如主库/oradata/tbs01.dbf，备库应映射为/backup/tbs01.dbf而非/backup/tbs02.dbf）。
最容易被忽略的是：即使standby_file_management设为AUTO，对已存在的UNNAMED文件也完全无效——它只管后续新增文件。所以每次遇到UNNAMED，都得手动处理，没法“一键修复”。
