根本原因是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;前，必须确保该文件确实不在磁盘上，否则会报错
手动清理备库残留数据文件的正确步骤
核心原则：先让控制文件“忘记”这个文件，再从 OS 层确认清理。不能跳过 OFFLINE DROP 直接删文件，否则下次启动或恢复会失败。
- 停止备库恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 对每个已丢失的文件执行：
ALTER DATABASE DATAFILE '<full_path>' OFFLINE DROP;（注意单引号，路径大小写敏感） - 打开备库到 MOUNT 状态（如果还没）：
STARTUP MOUNT; - 从控制文件中清除记录：
ALTER DATABASE DATAFILE '<full_path>' OFFLINE DROP;执行后，该文件就从V$DATAFILE消失了 - 重启恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; - 验证：
SELECT NAME, STATUS FROM V$DATAFILE WHERE NAME LIKE '%<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这类提示，往往意味着恢复进程卡在某个文件缺失上，而不是网络或归档问题
