Broker 配置必须启用且主备库 dg_broker_start 均为 TRUE，dgmgrl 连接需通过 db_unique_name，SwitchoverStatus 主库须为 TO STANDBY 或 SESSIONS ACTIVE、备库须为 TO PRIMARY，且 transport/apply lag 应接近 0 秒。
确认 Broker 配置已启用且状态正常
没开 DG_BROKER_START，dgmgrl 就是个摆设。先连上主库查真实状态，别信“我记得开了”这种感觉：
-
show parameter dg_broker_start必须返回TRUE，否则在主备两边都执行alter system set dg_broker_start=true; - 用
dgmgrl /连本地，再connect sys@<code>db_unique_name确保能连上两边（注意不是 service_name） -
show configuration输出里不能有WARNING或ERROR；若提示ORA-16664: unable to receive the result from a database，大概率是监听没通、tnsnames.ora 缺项或密码不对 - 特别注意：Broker 不允许同时存在手动配置的
LOG_ARCHIVE_DEST_2（带SERVICE=的），否则switchover会直接报错拒绝执行
执行 switchover 前必须验证的三项状态
dgmgrl 不会替你判断业务是否就绪，它只认数据库层面的同步和角色可切换性。漏掉任意一项，切完就卡住：
-
show database verbose "<code>primary_db_unique_name" 中SwitchoverStatus必须是TO STANDBY或SESSIONS ACTIVE；如果是NOT ALLOWED或FAILED，说明日志没传完、gap 没补、或保护模式不匹配 -
show database verbose "<code>standby_db_unique_name" 中SwitchoverStatus必须是TO PRIMARY；如果还是NOT ALLOWED，常见原因是备库没开实时应用：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 检查
transport lag和apply lag：运行show dataguard_status "<code>standby_db_unique_name"，找含transport lag和apply lag的行，值应为0 seconds或极小（V$ARCHIVED_LOG 序号一致——ADG 下日志可能已接收但没应用完
dgmgrl 执行切换的最小安全命令集
别图省事只敲一条 switchover to。生产环境必须加校验和超时控制，否则命令卡住你都不知道卡在哪：
- 先做预检：
validate database "<code>standby_db_unique_name" —— 这步会触发 Broker 内部全链路检查，比人肉查视图更准 - 正式切换：
switchover to "<code>standby_db_unique_name"；如果主库还有活跃会话，Broker 默认会等 30 秒后失败，不会自动加with session shutdown - 真要强制关会话，得显式写：
switchover to "<code>standby_db_unique_name" with force（注意是with force，不是 SQL 里的with session shutdown） - 切换完成后立刻查：
show configuration，确认角色已互换，且新主库State是SUCCESS，新备库是APPLYING_LOG；若新备库停在WAITING_FOR_LOGS，说明日志传输没起来，回去检查log_archive_dest_2是否被 Broker 正确接管
切完立刻要做的三件事，否则容易回不去
Broker 切换完只是角色变了，很多配套动作它不会帮你自动补全：
- 新主库上立刻执行
alter system switch logfile;，然后查archive log list确认归档已写到新位置；否则旧主库（现备库）可能因FAL_SERVER指向错误而拉不到归档 - 新备库（原主库）如果之前是
READ ONLY WITH APPLY，切换后默认进MOUNTED状态，必须手工启日志应用：edit database "<code>old_primary_db_unique_name" set state = "APPLY-ON"; - 检查
sqlnet.ora和 Oracle Wallet：如果用了 FSFO，Observer 进程依赖 Wallet 存的 sys 密码。切完后若 Observer 报ORA-01017，不是密码错了，而是 Wallet 没同步到新主库的对应路径下
LOG_ARCHIVE_DEST_2 是否自动指向了新主库，以及 Observer 进程是否仍在监控正确的 DB_UNIQUE_NAME。 
