ora-16775是data guard broker因备库未满足安全切换条件（如mrp未运行、归档未应用完、log_archive_dest_2异常等）而主动拒绝switchover的保护性警告，非配置错误，需先验证并修复底层状态再重试。
ora-16775 不是状态异常，而是 data guard broker 拒绝执行 switchover 的明确警告：它检测到备库尚未准备好接收角色切换，强行继续大概率导致数据丢失。
ORA-16775 错误的真实含义和常见诱因
这个错误常被误读为“配置错误”，其实它是 Broker 的保护机制触发。核心意思是：“我查了，当前备库还没应用完所有归档日志，或者它的恢复进程没在运行，现在切过去不安全”。不是命令写错了，是条件没满足。
常见诱因包括：
- 备库的
MRP进程未启动或已中断（SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY中没有APPLYING_LOG） - 主库归档目标
LOG_ARCHIVE_DEST_2状态为ERROR或DEFERRED（查V$ARCHIVE_DEST_STATUS的STATUS和ERROR列） - 备库控制文件里残留旧角色信息，比如
SWITCHOVER_STATUS仍是NOT ALLOWED或SESSIONS ACTIVE，但实际无活跃会话 - DG Broker 配置中该备库的
State显示为UNKNOWN或OFFLINE（SHOW DATABASE VERBOSITY 'standby_db_name'可见）
用 DGMGRL 强制重置前必须先确认的三件事
别急着 ENABLE 或 REINSTATE，先确认底层是否真“干净”：
- 在备库上跑：
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或空 - 确认主库
SWITCHOVER_STATUS是TO STANDBY，且LOG_ARCHIVE_DEST_STATE_2是ENABLE—— 否则 Broker 根本不会尝试发切换请求
DGMGRL 中重置并推进 Switchover 的实操步骤
Broker 不提供“强制忽略警告”的开关，所谓“强制重置”其实是让 Broker 重新评估状态、刷新缓存、再试一次。关键动作不是暴力命令，而是顺序和验证：
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 先在任意节点连接 Broker：
dgmgrl sys/password@primary_db（连当前主库） - 执行健康检查：
SHOW CONFIGURATION—— 输出末尾必须是Configuration status: SUCCESS；如果不是，先用VALIDATE DATABASE 'standby_db_name'查具体哪项失败 - 如果备库显示
State: UNKNOWN，先手动启用：ENABLE DATABASE 'standby_db_name'；若报错，看提示是网络不通、密码不对，还是监听没注册服务（此时需在备库执行ALTER SYSTEM REGISTER） - 确认无误后，发起切换：
SWITCHOVER TO 'standby_db_name'—— 注意这里必须用DB_UNIQUE_NAME，不是服务名或实例名 - 切换过程中 Broker 会自动调用
VERIFY步骤；若仍报 ORA-16775，说明VALIDATE检出硬性不满足项，不能跳过
绕过 DGMGRL 直接用 SQL 手动切换的兜底方案
当 Broker 卡死在 ORA-16775 且反复 VALIDATE 无解时，可退回到 SQL 层操作，但前提是已人工确认所有日志已应用、MRP 正常、无活跃事务：
- 主库执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN - 备库执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY - 原主库（现备库）：
SHUTDOWN IMMEDIATE→STARTUP MOUNT→ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 原备库（现主库）：
ALTER DATABASE OPEN - 切完立刻查：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE和V$ARCHIVE_DEST_STATUS.STATUS
手动切换成功后，记得回 DGMGRL 执行 EDIT CONFIGURATION SET PROPERTY 'ProtectionMode' = 'MaxAvailability' 等同步 Broker 元数据，否则下次 SHOW CONFIGURATION 仍会报错。
最易被忽略的是：ORA-16775 报出来时，Broker 已经把错误原因写进了备库的 alert 日志，搜索 SWITCHOVER VERIFY 关键字比盲试命令更高效。它不是故障，是提醒你——再往前一步，就不是“平滑切换”，而是“数据冒险”了。
