Oracle 19c中如何利用FastStart Failover提高系统可用性？-Oracle-PHP中文网

FSFO启用后不自动切换是因为五项硬性前提缺一不可：V$DATABASE.FSFO_STATUS必须为SYNCHRONIZED；主备库均启用FLASHBACK DATABASE；LOG_ARCHIVE_DEST_n含合法VALID_FOR；PROTECTION_MODE为MAXIMUM AVAILABILITY/PERFORMANCE；备库为PHYSICAL STANDBY且OPEN_MODE=READ ONLY WITH APPLY。

FSFO 为什么启用后不自动切换？五项硬性前提缺一不可

不是配置完 enable fast_start failover 就能自动切——v$database.fsfo_status 必须是 synchronized，否则 observer 永远卡在 waiting for primary to become unavailable。

FLASHBACK DATABASE 必须在主库和备库都启用：ALTER DATABASE FLASHBACK ON；备库启用前需先 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，再开 flashback，最后重启 apply
LOG_ARCHIVE_DEST_n 中必须同时存在两组 VALID_FOR：主库上要含 VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE)，备库上要含 VALID_FOR=(ONLINE_LOGFILES,STANDBY_ROLE)
保护模式必须是 MAXIMUM AVAILABILITY 或 MAXIMUM PERFORMANCE（19c 支持后者）；用 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE 切换后需重启 broker 配置
备库必须是 PHYSICAL STANDBY 且 OPEN_MODE = 'READ ONLY WITH APPLY'；SELECT OPEN_MODE FROM V$DATABASE 必须返回该值，MOUNTED 或纯 READ ONLY 都不行
SHOW CONFIGURATION 输出必须为 Success，且无 WARNING；任意一项校验失败，ENABLE FAST_START FAILOVER 会报错或静默失效

dgmgrl 配置顺序错一步，FSFO 就不会生效

所有操作必须走 dgmgrl 连接 Broker，SQL*Plus 命令完全无效。observer 启动必须本地执行，远程调用或后台 nohup 会导致进程不可靠。

连接 Broker：用 dgmgrl sys/password@primary_db（注意是 Broker 监听名，不是数据库实例名）
设目标备库：EDIT DATABASE 'standby_db' SET PROPERTY 'FastStartFailoverTarget' = 'standby_db'；若未显式设置，FSFO 默认不指定目标
调阈值参数：EDIT DATABASE 'standby_db' SET PROPERTY 'FastStartFailoverThreshold' = 30（单位秒，建议跨地域部署时设为 60）
启用 FSFO：ENABLE FAST_START FAILOVER；成功后 SHOW CONFIGURATION 中 Fast-Start Failover 显示 ENABLED
启动 observer：dgmgrl -silent "START OBSERVER" 必须在独立主机上、本地终端运行；日志默认落于 $ORACLE_HOME/rdbms/log/drc*.log，出问题第一眼看这里

Observer 单点=FSFO 失效，双 observer 不是可选而是强制要求

Oracle 19c 要求至少两个 observer 达成投票共识才允许 failover，单个 observer 进程宕机即导致整个 FSFO 停摆——这不是容错设计，是硬性机制。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

两个 observer 必须部署在不同物理节点或可用区，禁止共用同一台主机、同一网络出口或同一存储路径
各自 tnsnames.ora 中必须正确定义 PRIMARY_DB 和 STANDBY_DB，且双向 tnsping + sqlplus /@PRIMARY_DB 全通
启动命令带配置文件：START OBSERVER observer1.ora，其中 observer1.ora 内容仅为一行：CONNECT IDENTIFIER IS PRIMARY_DB（另一台可一致，19c 允许）
禁用 nohup dgmgrl &；改用 systemd 管理进程，确保异常退出有日志、有告警、能自拉起

客户端连不上新主库？TNS 层没配好，FSFO 白启

FSFO 切换成功 ≠ 应用自动连上新主库。如果 tnsnames.ora 没启用 FAILOVER=ON 和 CONNECT_TIMEOUT，客户端仍会卡在旧地址超时（20–30 秒），业务感知不到切换。

FAILOVER=ON 和 LOAD_BALANCE=ON 必须同级放在 ADDRESS_LIST 内，写在 DESCRIPTION 外层无效
每个 ADDRESS 必须单独配 CONNECT_TIMEOUT=8（单位秒），否则第一个地址失败后仍等 TCP 默认超时
FAILOVER_MODE 是会话级增强，对连接建立阶段无效；短连接场景靠 CONNECT_TIMEOUT + FAILOVER=ON 就够用
JDBC URL 中 load_balance 值必须小写 on，大写或首字母大写会被忽略

FSFO 的复杂点不在命令多，而在所有链路必须闭环：broker 状态、flashback、valid_for、observer 投票、tns 连接策略，任意一环松动都会导致“看起来配好了，实际切不动”。最容易被忽略的是 observer 日志里反复出现的 ORA-16664（收不到备库响应）和 tnsnames.ora 中 CONNECT_TIMEOUT 漏配——这两处问题占线上故障的七成以上。