删除数据文件后Data Guard不会自动同步，备库控制文件仍保留已删文件记录，导致ORA-01157/ORA-01110错误；需在备库MOUNT状态下执行ALTER DATABASE DATAFILE X OFFLINE DROP清除元数据，再重启MRP。
删除数据文件后，Data Guard 不会自动同步该操作——主库上 DROP TABLESPACE 或 ALTER DATABASE DATAFILE ... OFFLINE DROP 之类操作，不会触发备库对应文件的删除。备库仍保留已删文件的控制文件记录，后续启动或恢复时会报 ORA-01157、ORA-01110 等错误。
主库删文件后备库报 ORA-01157：无法识别/锁定数据文件
这是最常见现象。备库控制文件里还存着已被主库删掉的数据文件路径和编号，但物理文件已不存在，MRP 进程一尝试访问就失败并中断。
- 先确认错误来源：查备库
alert.log，定位到类似ORA-01157: cannot identify/lock data file X - see DBWR trace file的行 - 再查控制文件中残留记录：
SELECT FILE#, NAME, STATUS FROM V$DATAFILE WHERE FILE# = X;（X 是报错中的文件号） - 若
STATUS为OFFLINE或RECOVER，且NAME指向一个不存在的路径，基本可判定是“幽灵文件”
手动清理备库控制文件中的残留数据文件记录
不能直接删控制文件，也不能用 ALTER DATABASE DATAFILE ... OFFLINE DROP —— 备库不允许该命令。正确做法是让备库控制文件“忘记”这个文件：
- 停止 Redo Apply：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 以
MOUNT状态启动备库：SHUTDOWN IMMEDIATE; STARTUP MOUNT; - 从控制文件中移除文件：
ALTER DATABASE DATAFILE X OFFLINE DROP;（X 是文件号，不是路径） - 打开备库（只读）：
ALTER DATABASE OPEN READ ONLY;（Active Data Guard 场景下可跳过此步，直接下一步） - 重启 Redo Apply：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
注意：OFFLINE DROP 在备库上仅作用于控制文件元数据，不操作磁盘，安全；但必须在 MOUNT 状态下执行，OPEN 状态下会报 ORA-01145。
为什么不能靠重新同步（geopg update）或重建备库来解决？
geopg update 只刷新保护组元数据，不触碰数据库物理结构；RMAN 重新同步或重建备库成本过高，且掩盖了根本问题——这类删除操作本就不该绕过 Data Guard 生命周期管理。
- 真正合规的做法：主库删文件前，应先在备库上手动 offline 对应文件（如果业务允许），或使用
ADG+FLASHBACK DATABASE回退后再统一操作 - 若已误删，上述
OFFLINE DROP是最快恢复路径；但之后需检查V$ARCHIVED_LOG中是否有因该文件导致的归档应用中断（APPLIED = 'NO'且NAME涉及该表空间） - 长期看，避免直接删文件：改用
ALTER TABLESPACE ... DROP INCLUDING CONTENTS AND DATAFILES（需主备库均开启OMF且配置一致），才能让 Data Guard 自动传播删除动作
关键点在于：Data Guard 同步的是 Redo 流，不是文件系统操作。任何绕过 Redo 机制的物理变更（rm、mv、直接删文件），都会在备库留下不一致状态，必须人工干预修正控制文件视图——这一步容易被忽略，却直接决定 MRP 能否继续推进。
