DGMGRL的SWITCHOVER TO常卡在ORA-16775，因Broker检测到备库未就绪：MRP未运行、归档目标异常、SWITCHOVER_STATUS非“TO STANDBY”或State为UNKNOWN，须先VALIDATE并手动验证三态。
dgmgrl 本身不支持真正“一键式”切换，所谓“一键”只是省略了 sql 层的手动开库、启 mrp 等步骤，但前提是 broker 配置干净、状态健康，否则会直接报 ora-16775 拒绝执行。
为什么 DGMGRL 的 SWITCHOVER TO 常卡在 ORA-16775
这个错误不是命令写错了，是 Broker 主动拒绝——它检测到备库还没准备好接管主角色。常见真实原因有：
-
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY中没有APPLYING_LOG进程（MRP 没跑或已中断） - 主库的
LOG_ARCHIVE_DEST_2在V$ARCHIVE_DEST_STATUS中显示STATUS = 'ERROR'或'DEFERRED' - 备库控制文件里
SWITCHOVER_STATUS仍是'NOT ALLOWED'，即使你确认没活跃会话，也可能是 Broker 缓存未刷新 -
DGMGRL> SHOW DATABASE VERBOSITY 'standby_db_name'显示该库State = UNKNOWN，说明 Broker 连不上或监听配置不对
执行前必须手动验证的三个关键状态
别急着敲 SWITCHOVER TO，先连上备库查这三条：
- 归档是否全应用：
SELECT MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG GROUP BY APPLIED—— 确保APPLIED = 'YES'的最大SEQUENCE#和主库当前V$ARCHIVE_DEST_STATUS.ARCHIVED_THREAD#一致 - 是否实时应用：
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2必须返回'MANAGED REAL TIME APPLY'，不是'IDLE'也不是空 - 主库是否已就绪：
SELECT DATABASE_ROLE, SWITCHOVER_STATUS, LOG_ARCHIVE_DEST_STATE_2 FROM V$DATABASE, V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2—— 要同时满足DATABASE_ROLE = 'PRIMARY'、SWITCHOVER_STATUS = 'TO STANDBY'、LOG_ARCHIVE_DEST_STATE_2 = 'ENABLE'
DGMGRL 中实际能走通的切换流程
Broker 不提供“强制忽略”，所谓“重试”其实是让它重新评估。顺序不能错：
- 在 DGMGRL 中先运行
VALIDATE DATABASE 'standby_db_name'—— 如果报错，说明底层硬性条件不满足，必须回 SQL 层修复，不能跳 - 如果
VALIDATE通过但SWITCHOVER TO 'standby_db_name'仍报 ORA-16775，检查SHOW CONFIGURATION输出中所有数据库的State是否都是ONLINE；若某库为UNKNOWN，先在对应节点执行ALTER SYSTEM REGISTER，再ENABLE DATABASE 'xxx' - 切换发起后，Broker 会自动调用
VERIFY步骤；若失败，它不会继续，也不会自动重启实例——新主库停在MOUNT，需人工ALTER DATABASE OPEN；新备库也不会自动启 MRP，得手动RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
绕过 DGMGRL 的兜底方案：SQL 层直接切
当 Broker 卡死且反复 VALIDATE 失败时，直接进 SQL*Plus 执行：
- 在原主库：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN - 在原备库：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY，然后ALTER DATABASE OPEN - 立刻在新备库启动恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 注意：此时 DG Broker 配置已失效，需用
DGMGRL> REMOVE CONFIGURATION清掉旧配置，再重建
Broker 切换表面简洁，但它的“智能”完全依赖底层状态的实时性和一致性。最容易被忽略的是静态监听器配置和 GLOBAL_DBNAME 的拼写——哪怕只差一个下划线，State = UNKNOWN 就会一直卡住，而错误日志里根本不会明说这点。
