如何解决DG主库执行Drop Tablespace备库未同步_STANDBY_FILE

根本原因是standby_file_management=auto仅自动同步add/resize操作，不处理drop tablespace等ddl引发的物理文件删除，导致备库控制文件仍记录已删文件路径，进而触发ora-01157等错误。

为什么 `drop tablespace` 在主库执行后备库没反应

根本原因不是 dg 同步机制失效，而是 standby_file_management 参数默认值为 auto 时，仅对 add、resize 类操作自动同步文件（如数据文件增删），但 drop tablespace 属于 ddl 元数据变更，不触发备库自动清理对应数据文件——它只同步日志里记录的 ddl，不主动删除物理文件。

常见错误现象：SELECT * FROM V$DATAFILE 在备库仍能看到已删除表空间的数据文件路径；备库告警日志出现 ORA-01157: cannot identify/lock data file 或 ORA-01110 报错；RECOVER MANAGED STANDBY DATABASE 持续挂起或报错。

STANDBY_FILE_MANAGEMENT=AUTO 不等于“全托管”，它只管“加”和“调”，不管“删”
主库 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 的 AND DATAFILES 部分在备库完全无效
如果主库用的是 OMF（Oracle Managed Files），备库可能自动生成同名文件，掩盖问题，但实际未清理旧文件

如何确认备库是否已丢失该表空间的物理文件

别只查 DBA_TABLESPACES，得看文件是否还在磁盘上且被 Oracle 认知。重点检查三层状态：数据库字典、控制文件记录、操作系统路径。

查备库 V$DATAFILE：确认对应文件 STATUS 是否为 OFFLINE 或 INVALID，NAME 字段是否指向已不存在的路径
查备库 V$TABLESPACE 和 DBA_TABLESPACES：确认表空间是否还存在（有时 DROP 未完全传播，字典残留）
登录备库服务器，用 ls -l 检查 NAME 列出的路径是否存在；若不存在，说明文件已被主库删掉，但备库控制文件还没更新
运行 ALTER DATABASE DATAFILE '<path>' OFFLINE DROP;</path> 前，必须确保该文件确实不在磁盘上，否则会报错

手动清理备库残留数据文件的正确步骤

核心原则：先让控制文件“忘记”这个文件，再从 OS 层确认清理。不能跳过 OFFLINE DROP 直接删文件，否则下次启动或恢复会失败。

停止备库恢复：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
对每个已丢失的文件执行：ALTER DATABASE DATAFILE '<full_path>' OFFLINE DROP;</full_path>（注意单引号，路径大小写敏感）
打开备库到 MOUNT 状态（如果还没）：STARTUP MOUNT;
从控制文件中清除记录：ALTER DATABASE DATAFILE '<full_path>' OFFLINE DROP;</full_path> 执行后，该文件就从 V$DATAFILE 消失了
重启恢复：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
验证：SELECT NAME, STATUS FROM V$DATAFILE WHERE NAME LIKE '%<tablespace_name>%';</tablespace_name> 应无返回

`STANDBY_FILE_MANAGEMENT` 设置为 `MANUAL` 是更安全的选择吗

不是更安全，而是更可控——但代价是所有文件变更都得人工干预。设成 MANUAL 后，主库加数据文件，备库不会自动创建，反而更容易暴露问题，但也避免了 AUTO 下“删不干净”的静默故障。

AUTO 适合稳定、少结构性变更的环境；一旦有 DROP TABLESPACE、ALTER DATABASE RENAME FILE 等操作，就得人工兜底
MANUAL 要求 DBA 对每次主库文件操作都同步执行备库命令（如 ALTER DATABASE CREATE DATAFILE），运维成本高，但行为可预测
Oracle 官方文档明确说明：STANDBY_FILE_MANAGEMENT 不处理 DROP 类操作，这是设计使然，不是 bug
真正容易被忽略的点：备库 alert 日志里 Managed Standby Recovery not using Real Time Apply 这类提示，往往意味着恢复进程卡在某个文件缺失上，而不是网络或归档问题