ORA-01157报错源于备库控制文件仍登记已删除数据文件路径，需先查v$datafile及文件系统确认缺失，再以MOUNT状态执行ALTER DATABASE DATAFILE ... OFFLINE DROP清理元数据。
备库报 ORA-01157：无法识别/锁定数据文件
这是主库删了数据文件、但备库没同步感知时最典型的症状。oracle 备库的 mrp 进程在尝试恢复归档时，发现控制文件里还登记着那个已不存在的文件路径，直接卡住并报错：ora-01157: cannot identify/lock data file <n>。这不是归档中断或网络问题，而是备库元数据和物理文件状态不一致。
关键判断：先确认是不是真被删了——登录备库查 v$datafile 和实际文件系统：
SELECT file#, name, status FROM v$datafile WHERE file# = <n>;
再用操作系统命令看文件是否存在：ls -l <datafile_path>。如果查不到，说明文件确实没了，得手动清理控制文件里的残留记录。
手动从备库控制文件中删除数据文件记录
不能直接删控制文件，也不能停 MRP 后用 ALTER DATABASE DATAFILE ... OFFLINE DROP（这在只读备库上会报 ORA-16000: database open for read-only access）。唯一安全路径是：临时把备库切换成 MOUNT 状态，用 ALTER DATABASE DATAFILE ... OFFLINE DROP 标记文件为离线并丢弃，再打开数据库。
- 停止恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 关闭数据库：
SHUTDOWN IMMEDIATE; - 启动到 MOUNT：
STARTUP MOUNT; - 执行离线丢弃：
ALTER DATABASE DATAFILE <file_id> OFFLINE DROP;（注意：这里必须用file_id，不是文件名） - 打开备库：
ALTER DATABASE OPEN; - 重启 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
做完这步，v$datafile 里该文件状态变成 OFFLINE，且不再参与恢复流程；v$recover_file 中也不再出现它。
为什么不能直接删控制文件或用 DROP TABLESPACE？
控制文件是二进制结构，人工编辑会彻底损坏它；而 DROP TABLESPACE 在备库上根本不可用——备库没有 DML 权限，连 DROP 的语法都会被拒绝。更危险的是，有人试过在备库上用 rm 直接删文件再重建同名空文件，结果导致后续应用归档时报 ORA-00600 内部错误，因为 Oracle 检测到文件头 SCN 和控制文件登记值严重不匹配。
核心原则：备库的一切元数据变更，必须通过 SQL 命令触发 Oracle 自己更新控制文件，而不是绕过它去碰磁盘或二进制内容。
后续主库加新数据文件时，备库怎么自动同步？
只要主库开启了 STANDBY_FILE_MANAGEMENT=AUTO（默认就是），新增 DATAFILE 会自动传播到备库并创建对应文件。但如果之前你手动清过控制文件，这个参数可能被意外关掉——检查：SHOW PARAMETER STANDBY_FILE_MANAGEMENT。如果不是 AUTO，立刻设回去：ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;。
另外，如果主库删的是整个表空间（DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES），备库不会自动删文件，仍需按上面流程手动清理控制文件条目——Oracle 只同步“加”，不同步“删”。
真正容易被忽略的是：做完所有操作后，别忘了验证 v$archived_log 的 APPLIED 列是否持续更新，以及 SELECT MAX(sequence#) FROM v$archived_log WHERE applied='YES'; 是否跟主库一致。差一个归档，就等于丢了数据。
