show configuration显示success不代表broker真正可用，因其仅校验元数据完整性，不检查日志传输与应用状态；必须验证v$database.fsfo_status为synchronized、v$managed_standby中mrp0状态为applying_log且sequence#递增、备库open_mode含with apply。
SHOW CONFIGURATION 输出 SUCCESS 不代表就绪，必须查 V$DATABASE.FSFO_STATUS 和 V$MANAGED_STANDBY 才算真正可用。
为什么 SHOW CONFIGURATION 显示 SUCCESS 还是切不动
Broker 的 SHOW CONFIGURATION 只校验 Broker 元数据结构是否完整，不检查底层日志传输与应用状态。常见假成功场景包括：
主库归档目标 LOG_ARCHIVE_DEST_2 状态为 DEFERRED 或 ERROR；
备库 V$DATABASE.OPEN_MODE 是 READ ONLY 而非 READ ONLY WITH APPLY；
主备库时间不同步导致 Broker 心跳超时，V$DATAGUARD_STATS 中 apply lag 持续增长但不报错。
必须人工验证的三个核心视图
执行切换或启用 FSFO 前，以下查询缺一不可：
-
SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE FROM V$DATABASE;—— 主库必须为PRIMARY，备库必须为PHYSICAL STANDBY且OPEN_MODE含WITH APPLY -
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';—— STATUS 必须是APPLYING_LOG，SEQUENCE# 应持续递增 -
SELECT FSFO_STATUS FROM V$DATABASE;—— 值必须为SYNCHRONIZED；若为NOT SYNCHRONIZED，说明日志同步链路已断，即使 Broker 显示 ENABLED 也无效
DGMGRL 中 VALIDATE DATABASE 的真实作用
VALIDATE DATABASE 'standby_db_name' 不是“一键修复”，而是触发 Broker 对该库做一次深度探活，输出具体失败项。高频返回错误包括：ORA-16810: multiple errors or warnings detected for database：需配合 SHOW DATABASE VERBOSITY 'standby_db_name' 查明细ORA-16792: configuration property is inconsistent with database setting：通常是 LOG_ARCHIVE_DEST_2 的 DB_UNIQUE_NAME 值和实际备库不匹配ORA-16625: cannot reach database：不是网络不通，而是监听未注册 <db_unique_name>_DGMGRL</db_unique_name> 静态服务名
Observer 启动前最后确认点
FSFO 场景下，START OBSERVER 成功只代表进程起来，不代表能接管。务必在 Observer 日志（$ORACLE_HOME/rdbms/log/drc*.log）里确认最后一行是：FSFO observer is now monitoring the configuration
而不是反复出现：Waiting for primary to become unavailable
后者说明 V$DATABASE.FSFO_STATUS 仍为 NOT SYNCHRONIZED，或 StaticConnectIdentifier 中漏了 (INSTANCE_NAME=...) 和 (SERVER=DEDICATED)。
