switchover成功关键在前置检查：主备库switchover_status须合规，归档传输正常，log_archive_config双向配置，推荐用dgmgrl执行并及时更新应用连接配置。
Switchover 不是“执行一条命令就完事”，失败基本都卡在前置状态没校验清楚。真正能一次成功的切换，90%的功夫花在检查上，而不是执行上。
查 SWITCHOVER_STATUS 值是否允许切换
这是最常被跳过的一步，但直接决定后续命令是否 hang 或报 ORA-16129。必须分别在主库和备库查：
- 主库执行
SELECT SWITCHOVER_STATUS FROM V$DATABASE;—— 必须返回TO STANDBY或SESSIONS ACTIVE - 备库执行同语句 —— 必须返回
TO PRIMARY或SESSIONS ACTIVE - 如果主库是
SESSIONS ACTIVE，后续ALTER DATABASE COMMIT TO SWITCHOVER必须加WITH SESSION SHUTDOWN，否则会卡住 - RAC 环境下，要先确认只剩一个实例在线（
SELECT INSTANCE_NAME FROM GV$INSTANCE;），否则报ORA-01105
确保 LOG_ARCHIVE_DEST_STATE_2 是 ENABLE 且无积压
主库归档发不出去，备库永远收不到日志，SWITCHOVER 会因等待日志而超时或报 ORA-16139。
- 查主库：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——STATUS必须是VALID，ERROR列为空 -
LOG_ARCHIVE_CONFIG必须双向包含主备DB_UNIQUE_NAME，例如：'DG_CONFIG=(orcl,orcl_stby)'，漏掉任一方向会导致 DGMGRL 无法识别角色关系 - 备库
ARCHIVE_LAG_TARGET不建议设过大（如 > 1800），否则可能人为延迟归档传输
用 DGMGRL 执行切换比 SQL*Plus 更稳
Broker 自动校验依赖项、串行化操作、更新配置元数据，比手敲 SQL 少踩一半坑。
- 先连 Broker：
dgmgrl sys/password@primary_db（连当前主库，不是服务名） - 执行
SHOW CONFIGURATION—— 输出末尾必须是Configuration status: SUCCESS - 发起切换：
SWITCHOVER TO 'orcl_stby';（引号内是备库的DB_UNIQUE_NAME，不是SERVICE_NAME） - 切完立刻查新主库：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;—— 应为PRIMARY和READ WRITE - 别忘了在新主库执行
ALTER SYSTEM REGISTER;，否则监听器里注册的服务名还是旧的，应用连不上
切换后应用连不上？大概率是 TNS 或连接池没刷新
数据库秒级完成，但客户端缓存、连接池、JDBC 驱动不感知角色变更，导致 ORA-12514 或 ORA-01033。
- TNSNAMES.ora 中对应服务名必须配
(FAILOVER=ON)，且HOST和PORT指向新主库；静态 IP + 单点 VIP 是反模式 - JDBC 连接串里
service_name要设成新主库的DB_UNIQUE_NAME，不是ORACLE_SID - Oracle 12cR2+ 的 UCP/HikariCP 需启用
oracle.jdbc.replayEnabled=true和FastConnectionFailoverEnabled=true - 切完立刻在新主库跑
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME IN ('local_listener', 'remote_listener');，确认监听注册路径正确
真正麻烦的从来不是切换动作本身，而是切换前没发现的归档积压、Broker 配置未同步、或者应用侧硬编码了旧地址 —— 这些问题不会在 SWITCHOVER 命令里报错，但会让整个高可用设计形同虚设。
