必须先在备库offline对应文件，因data guard仅同步逻辑变更而不管理物理文件增删，直接主库删除会导致备库ora-01116/ora-01110报错及redo apply中断；正确流程是主库操作前人工干预备库状态，确认无活跃对象后执行alter database datafile ... offline，或利用adg+flashback统一操作。
主库删数据文件前，必须先在备库 offline 对应文件
直接在主库执行 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 或 ALTER DATABASE DATAFILE '...' OFFLINE DROP，会导致备库报错 ORA-01116、ORA-01110，甚至中断 Redo Apply。根本原因是 Data Guard 不自动同步物理文件的增删操作——它只同步逻辑变更（如 DDL/DML 产生的 redo），不管理文件系统层面的文件存在性。
正确做法是：主库删之前，先人工干预备库状态：
- 确认该数据文件所属表空间无活跃对象（查
dba_segments和v$session） - 在备库执行
ALTER DATABASE DATAFILE '/path/to/file.dbf' OFFLINE（不是OFFLINE DROP，除非你确定不再需要恢复） - 若备库是 ADG（Active Data Guard）且开启
FLASHBACK DATABASE，可先 flashback 到删文件前 SCN，再统一操作 - 主库完成删除后，用
ALTER DATABASE CREATE DATAFILE在备库重建（仅限物理备库），或靠 RMAN restore（更稳妥）
误删后最快恢复路径：备库 OFFLINE DROP + 检查归档应用状态
如果已经跳过前置步骤、主库已删文件且备库开始报错，不要重启 MRP 或盲目 restore。此时最短路径是让备库“承认”该文件已不存在：
- 在备库执行
ALTER DATABASE DATAFILE '/path/to/file.dbf' OFFLINE DROP - 立刻查
V$ARCHIVED_LOG：是否有APPLIED = 'NO'且NAME涉及该表空间的归档？若有，说明这部分 redo 依赖已被删的文件结构，MRP 将卡住 - 运行
SELECT * FROM V$ARCHIVE_GAP;确认是否存在 gap；若有，需从主库手动拷贝缺失归档并注册（ALTER DATABASE REGISTER PHYSICAL LOGFILE） - 恢复 MRP 后，监控
V$MANAGED_STANDBY中MRP0进程状态是否为APPLYING_LOG
为什么不能靠 RMAN 重新同步或重建备库？
RMAN DUPLICATE 或 RECOVER DATABASE 确实能修复，但属于“高成本掩盖”：
-
geopg update只刷新保护组元数据，完全不触碰数据库物理结构 - RMAN 重建备库需停机、传输 TB 级数据、重放全部归档，RTO 动辄数小时
- 掩盖了流程漏洞：数据文件删改本应走变更管理流程，而非 DBA 手动 rm
- 若主库删的是系统关键表空间（如
SYSAUX），重建过程可能因字典不一致失败
临时文件和联机日志文件的删除逻辑完全不同
别把数据文件的处理方式套用到其他文件类型上：
- 临时文件（
tempfile）：主库DROP TABLESPACE TEMP ...不同步到备库，必须手动在备库删 OS 文件 +ALTER DATABASE TEMPFILE ... DROP - 联机日志（
LOGFILE）：主库ADD/DROP LOGFILE也不同步，需手动在备库执行相同语句，并确保STANDBY_FILE_MANAGEMENT=MANUAL期间操作 - 归档文件（
archivelog）：删的是已应用的旧归档，靠脚本查V$ARCHIVED_LOG WHERE APPLIED='YES' AND COMPLETION_TIME 再 <code>rm，不能只看文件名或 mtime
真正容易被忽略的点是：Data Guard 的“同步”有明确边界——它不管文件存不存在，只管 redo 能不能重放。一旦物理结构失配，后续所有自动化手段（包括 RMAN policy、ADG 自动回退）都会失效，只能靠人工对齐状态。操作前多一次 SELECT * FROM V$DATAFILE 主备比对，比出问题后花半天排查值回十倍。
