• 核心检查命令就这一条：SELECT FSFO_STATUS, DATABASE_ROLE, PROTECTION_MODE FROM V$DATABASE;
• 结果必须满足：主库角色（DATABASE_ROLE）是PRIMARY，备库角色是PHYSICAL STANDBY，并且其OPEN_MODE为READ ONLY WITH APPLY。
• 另外，主库上的LOG_ARCHIVE_DEST_STATE_2参数必须设为ENABLE，而且对应的DB_UNIQUE_NAME必须和FSFO配置里的一模一样，注意大小写敏感。

如果查出来FSFO_STATUS显示为STARTED，那意味着Observer进程要么还没连上，要么心跳通信中断了。这时候你就算把主库断电，触发的也只会是传统的手动故障转移（failover），而不是FSFO的自动切换。

模拟主库断电的正确操作顺序

真实的断电当然不可控，但我们的测试必须可控。直接来个shutdown abort？这招可不行。这种暴力关闭会绕过Data Guard的正常协议，导致Observer可能判定主库是“异常终止”，从而拒绝启动自动故障转移。

正确的操作顺序应该是这样：

• 第一步，先停掉主库的监听和归档传输：在主库执行ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;。这可以避免日志继续堆积，引发一些不必要的状态误判。
• 第二步，使用shutdown immediate命令来关闭主库实例。这种方式最接近“正常断电但保留了一定控制权”的场景。
• 第三步，立刻去观察Observer的日志：tail -f /path/to/observer.log。关键信号是看到Initiating Fast-Start Failover和Switchover target is now the new primary这样的记录。
• 最后，验证备库是否成功转正：检查其V$DATABASE.DATABASE_ROLE是否变成了PRIMARY，并且OPEN_MODE变为READ WRITE。

这里再强调一下，shutdown abort会导致Observer日志里出现ORACLE INSTANCE TERMINATED而非正常的INSTANCE SHUTDOWN，很大概率会触发Failover cancelled: Primary instance terminated abnormally的错误，让你的测试前功尽弃。

为什么Observer日志里一直卡在“Waiting for primary to become una vailable”

测试时最让人着急的情况之一，就是Observer日志反复打印“Waiting for primary to become una vailable”，切换却迟迟不触发。这通常不是Observer坏了，而是它没有收到主库“彻底失联”的明确信号。

FSFO机制依赖Observer通过SQL*Net定期去ping主库上一个特定的包（DBMS_DG.INITIATE_FS_FAILOVER）。这个ping操作需要主库能响应基础的SQL查询。

• 最常见的原因：防火墙。即使tnsping能通，防火墙的状态检测规则也可能阻断了Observer到主库1521端口的持续性连接。
• 另一个容易踩的坑：参数FAST_START_FAILOVER_THRESHOLD。它的默认值是30秒，但Observer实际的等待时间是这个阈值的3倍，也就是90秒。在这90秒内，只要有一次ping成功了，倒计时就会重置。
• 怎么验证？直接在Observer所在的机器上，手动执行一个到主库的简单查询，比如sqlplus sys/密码@primary_db as sysdba -c “SELECT 1 FROM DUAL;”。如果这个连接请求超时或者报出ORA-12170: TNS:Connect timeout occurred之类的错误，那才符合FSFO触发的网络条件。

顺便提个醒，别为了图快而随意调小FAST_START_FAILOVER_THRESHOLD。阈值设得太小，一次轻微的网络抖动就可能引发误切换，那可就得不偿失了。

切换后应用连不上新主库？检查这3个地方

FSFO成功切换了数据库角色，但应用却报连接错误？别慌，这太正常了。因为FSFO只负责数据库层面的故障转移，它可不会自动帮你修改TNS别名、连接字符串或者应用配置文件。

问题通常出在以下三个地方：

• 第一，应用使用的TNSNAMES.ORA文件。里面配置的服务名指向的IP地址很可能还是旧主库的。这就需要你提前规划好，比如使用SCAN（扫描IP）或者在ADDRESS_LIST中配置多个地址轮询。
• 第二，如果应用连接使用了Oracle Wallet，或者JDBC连接中设置了oracle.net.tns_admin属性，请确保Wallet里配置的服务别名（Alias）对应的是当前主库的DB_UNIQUE_NAME。
• 第三，也是最容易遗漏的一点：listener.ora配置文件。里面的SID_LIST_LISTENER配置项如果没有同步更新，新主库启动后，监听器可能无法识别这个新的GLOBAL_DBNAME，导致应用连接时报ORA-12514: TNS:listener does not currently know of service requested错误。

说到底，Observer不会去动任何网络或监听配置。这一部分的容灾路由，全靠你在架构设计阶段就做好预案。