必须在备库设为AUTO且处于MOUNT状态才生效；主库删除数据文件时，若备库STANDBY_FILE_MANAGEMENT=MANUAL（默认），MRP无法自动删除文件，仅标记为UNNAMED并报ORA-01111。
必须在主库和备库都设为 auto，且备库处于 mount 状态下才能生效；仅在主库设置不会自动“推”到备库。
为什么主库删了数据文件，备库报 ORA-01111 和 UNNAMED？
主库执行 ALTER DATABASE DATAFILE ... OFFLINE DROP 或 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 后，如果备库的 STANDBY_FILE_MANAGEMENT 是 MANUAL（默认值），MRP 进程无法自动删除对应文件，只能把该文件标记为 UNNAMED 并卡住恢复。此时查 V$RECOVER_FILE 会看到 ERROR 列含 FILE MISSING，V$DATAFILE 中对应路径是类似 /u01/app/oracle/product/dbs/UNNAMED00042 的占位路径。
设置 STANDBY_FILE_MANAGEMENT=AUTO 的实操要点
这不是“设一次就一劳永逸”的参数，必须分场景确认状态和作用域：
- 连接目标实例（主库或备库）后，先确认当前值：
SHOW PARAMETER standby_file_management或SELECT name, value, ispdb_modifiable FROM v$parameter WHERE name = 'standby_file_management' - 在备库上设置才真正影响备库行为；主库设置仅用于控制主库自身日志应用逻辑（极少用），对物理备库无直接作用
- 推荐命令带
SCOPE=SPFILE：ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=SPFILE;，避免实例重启后失效 - 若备库当前是
OPEN状态（如 ADG 实时查询模式），需先SHUTDOWN IMMEDIATE→STARTUP MOUNT再执行，否则报ORA-02095（参数不可动态修改） - 设完后必须重启备库（
STARTUP MOUNT即可，无需OPEN），否则新值不加载进内存
设成 AUTO 后，主库删文件，备库还用管吗？
仍需人工干预，但范围大幅收窄：
- 主库执行
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES→ 备库 MRP 自动识别并删除对应数据文件（路径由DB_FILE_NAME_CONVERT决定） - 主库执行
ALTER DATABASE DATAFILE ... OFFLINE DROP→ 备库不会自动删，因为该操作不生成归档日志事件；MRP 仍会卡在该文件，需手动ALTER DATABASE DATAFILE ... OFFLINE DROP或RECOVER后再ALTER DATABASE DATAFILE ... ONLINE - 若主库用了 ASM，而备库是文件系统，
DB_FILE_NAME_CONVERT必须精确匹配 ASM 别名转换逻辑，否则AUTO模式可能创建错路径甚至覆盖已有文件 - 设为
AUTO后，禁止对备库数据文件执行ALTER DATABASE RENAME FILE，否则报ORA-01511（“重命名操作不允许：备用文件管理为自动”）
验证是否真生效的三个关键检查点
别只信 SHOW PARAMETER 返回 AUTO 就算完事：
- 查
V$DATAGUARD_STATS中standby_file_management字段是否为AUTO（该视图反映实际运行时行为） - 主库新增一个测试表空间：
CREATE TABLESPACE tst_auto DATAFILE SIZE 10M;，切日志后观察备库V$DATAFILE是否多出对应文件（注意路径是否符合预期） - 主库删掉该表空间：
DROP TABLESPACE tst_auto INCLUDING CONTENTS AND DATAFILES;，再查备库V$DATAFILE对应记录是否消失、V$RECOVER_FILE是否无错误
最易被忽略的一点：当备库因故障恢复（如增量备份重建控制文件）后，STANDBY_FILE_MANAGEMENT 会被重置为 MANUAL —— 这是 Oracle 内部机制，不是 bug。每次做完恢复操作，必须显式重设并重启备库，否则下一次主库增删文件，又会回到 UNNAMED 状态。
