Oracle备库出现ORA-01110报错时怎样修复-Oracle-PHP中文网

ORA-01110是指示路径的“指路牌”，非独立错误；真正需处理的是前置主错误（如ORA-01157、ORA-01578、ORA-00376）及引号内路径的真实性，须先验证路径存在性、查DBA_DATA_FILES确认UNNAMED状态，再手动重建数据文件并确保SCN对齐。

oracle备库出现ora-01110报错时怎样修复

ORA-01110 在备库上几乎从不单独存在，它只是个“指路牌”——真正要修的，是它前面那个主错误（比如 ORA-01157、ORA-01578、ORA-00376）和引号里明写的路径是否真实可访问。别急着重建控制文件或改参数，先盯住那串路径。

看懂 `ORA-01110` 后面的路径才是第一动作

报错形如：ORA-01110: data file 75: '/u01/app/oracle/product/19c/dbhome_1/dbs/UNNAMED00075'，这个 '/u01/app/oracle/product/19c/dbhome_1/dbs/UNNAMED00075' 就是你要立刻验证的目标。

直接复制单引号内的完整路径（含引号），在终端执行 ls -l '/u01/app/oracle/product/19c/dbhome_1/dbs/UNNAMED00075' —— 几乎肯定返回 No such file or directory，因为 UNNAMEDxxx 是备库控制文件里的占位符，不是真实路径
如果是 ASM 路径（如 +DATA/ORCL/DATAFILE/users.256.123456789），必须切到 grid 用户，用 asmcmd ls -l +DATA/ORCL/DATAFILE/users.256.123456789 查；漏掉 + 或大小写错，就查不到
路径存在但文件名带 .bak 或 .old？说明原文件被覆盖，RMAN 实际写到了旧文件上，新路径下仍是空的

查 `DBA_DATA_FILES` 确认文件真实状态

ORA-01110 后面的路径只是控制文件里存的“名义路径”，不等于物理文件就真在那儿。得靠数据字典确认当前状态：

运行 SELECT FILE_ID, FILE_NAME, STATUS, ONLINE_STATUS FROM DBA_DATA_FILES WHERE FILE_ID = 75;
如果 FILE_NAME 是 UNNAMED00075，说明主库加了新数据文件但备库没同步成功，standby_file_management=AUTO 已失效
如果查询返回空行，说明该文件在主库已被删掉（比如执行过 DROP TABLESPACE 或 ALTER DATABASE DATAFILE ... OFFLINE DROP），但归档日志没传全，备库控制文件还残留旧状态
如果 STATUS = 'AVAILABLE' 但 ONLINE_STATUS = 'RECOVER'，说明 MRP 进程卡在恢复这个文件上，常见于归档中断后重连不全

UNNAMED 文件必须手动重建，不能靠 AUTO 恢复

这是 19c ADG 备库最常触发 ORA-01110 的场景：主库新增了数据文件，备库控制文件里只建了个空壳 UNNAMEDxxx，物理文件根本不存在。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

先切到手动模式：ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH;
查主库对应文件真实路径：SELECT FILE_NAME FROM V$DATAFILE WHERE FILE_ID = 75;，比如返回 '+DATA/ORCL/DATAFILE/users.256.123456789'
在备库执行重建：ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/19c/dbhome_1/dbs/UNNAMED00075' AS '+DATA/ORCL/DATAFILE/users.256.123456789'; —— 注意目标路径必须和 db_file_name_convert 规则一致，且 ASM 磁盘组要有写权限
立刻切回自动模式：ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;

修复后仍报 `ORA-01110`？检查 SCN 是否对齐

RESTORE 只拷文件，RECOVER 才刷检查点。如果恢复后立即 OPEN，而文件头的 CHECKPOINT_CHANGE# 还卡在旧值，Oracle 就会拒接打开并抛 ORA-01110 + ORA-01122。

查当前文件头 SCN：SELECT FILE#, CHECKPOINT_CHANGE# FROM V$DATAFILE_HEADER WHERE FILE# = 75;
查控制文件记录的 SCN：SELECT FILE#, CHECKPOINT_CHANGE# FROM V$DATAFILE WHERE FILE# = 75;
两者不一致？说明 RECOVER 没走完。别跳过，老实用 RECOVER DATAFILE 75; 或 RECOVER DATABASE UNTIL SCN xxx;
归档日志缺失时，RECOVER 会停在第一个断档点，RMAN 不报错但也不继续——用 LIST ARCHIVELOG ALL; 和 V$ARCHIVED_LOG 对比时间范围，确认是否覆盖到文件头 SCN