ORA-16775是Data Guard Broker因备库未满足安全切换条件（如MRP未运行、归档未应用完、LOG_ARCHIVE_DEST_2异常等）而主动拒绝switchover的保护性警告，非配置错误，需先验证并修复底层状态再重试。
ora-16775 不是状态异常，而是 data guard broker 拒绝执行switchover 的明确警告：它检测到备库尚未准备好接收角色切换，强行继续大概率导致数据丢失。
ORA-16775 错误的真实含义和常见诱因
这个错误常被误读为“配置错误”，其实它是 Broker 的保护机制触发。核心意思是：“我查了，当前备库还没应用完所有归档日志，或者它的恢复进程没在运行，现在切过去不安全”。不是命令写错了，是条件没满足。
常见诱因包括：
备库的
进程未启动或已中断（
中没有
）
主库归档目标
状态为
或
（查
的
和
列）
备库控制文件里残留旧角色信息，比如
仍是
或
，但实际无活跃会话
DG Broker 配置中该备库的
显示为
或
（
可见）
用 DGMGRL 强制重置前必须先确认的三件事
别急着
或
，先确认底层是否真“干净”：
在备库上跑：
—— 确保
的最大
和主库当前
中
一致
检查备库是否在实时应用：
必须返回
，不是
或空
确认主库
是
，且
是
—— 否则 Broker 根本不会尝试发切换请求
DGMGRL 中重置并推进 Switchover 的实操步骤
Broker 不提供“强制忽略警告”的开关，所谓“强制重置”其实是让 Broker 重新评估状态、刷新缓存、再试一次。关键动作不是暴力命令，而是顺序和验证：
纯CSS制作Switch动画开关按钮
纯CSS制作Switch动画开关按钮
下载
先在任意节点连接 Broker：
（连当前主库）
执行健康检查：
—— 输出末尾必须是
；如果不是，先用
查具体哪项失败
如果备库显示
，先手动启用：
；若报错，看提示是网络不通、密码不对，还是监听没注册服务（此时需在备库执行
）
确认无误后，发起切换：
—— 注意这里必须用
，不是服务名或实例名
切换过程中 Broker 会自动调用
步骤；若仍报 ORA-16775，说明
检出硬性不满足项，不能跳过
绕过 DGMGRL 直接用 SQL 手动切换的兜底方案
当 Broker 卡死在 ORA-16775 且反复
无解时，可退回到 SQL 层操作，但前提是已人工确认所有日志已应用、MRP 正常、无活跃事务：
主库执行：
备库执行：
原主库（现备库）：
→
→
原备库（现主库）：
切完立刻查：
和
手动切换成功后，记得回 DGMGRL 执行
等同步 Broker 元数据，否则下次
仍会报错。
最易被忽略的是：ORA-16775 报出来时，Broker 已经把错误原因写进了备库的 alert 日志，搜索
关键字比盲试命令更高效。它不是故障，是提醒你——再往前一步，就不是“平滑切换”，而是“数据冒险”了。
MRPSELECT PROCESS, STATUS FROM V$MANAGED_STANDBYAPPLYING_LOGLOG_ARCHIVE_DEST_2ERRORDEFERREDV$ARCHIVE_DEST_STATUSSTATUSERRORSWITCHOVER_STATUSNOT ALLOWEDSESSIONS ACTIVEStateUNKNOWNOFFLINESHOW DATABASE VERBOSITY 'standby_db_name'ENABLEREINSTATESELECT MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG GROUP BY APPLIEDAPPLIED = 'YES'SEQUENCE#V$ARCHIVE_DEST_STATUSARCHIVED_THREAD#SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2MANAGED REAL TIME APPLYIDLESWITCHOVER_STATUSTO STANDBYLOG_ARCHIVE_DEST_STATE_2ENABLEdgmgrl sys/password@primary_dbSHOW CONFIGURATIONConfiguration status: SUCCESSVALIDATE DATABASE 'standby_db_name'State: UNKNOWNENABLE DATABASE 'standby_db_name'ALTER SYSTEM REGISTERSWITCHOVER TO 'standby_db_name'DB_UNIQUE_NAMEVERIFYVALIDATEVALIDATEALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWNALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYSHUTDOWN IMMEDIATESTARTUP MOUNTALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECTALTER DATABASE OPENSELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASEV$ARCHIVE_DEST_STATUS.STATUSEDIT CONFIGURATION SET PROPERTY 'ProtectionMode' = 'MaxAvailability'SHOW CONFIGURATIONSWITCHOVER VERIFY