如何修复Oracle 19c DG中ORA-16175造成的无法进行角色转换-Oracle-PHP中文网

ora-16175是data guard因备库未完成日志应用而主动拦截切换的安全机制，非配置错误；需验证v$archived_log中applied='yes'的最大sequence#与主库一致、mrp进程为applying_log、recovery_mode为managed real time apply。

ora-16175 不是配置错误，而是 data guard 拒绝切换的明确安全拦截——它检测到备库尚未完成日志应用，强行切过去大概率丢数据。

查清备库是否真“吃干净”了所有归档

ORA-16175 的本质是 Broker 或 SQL 层发现备库控制文件里 SWITCHOVER_STATUS 仍为 NOT ALLOWED 或 SESSIONS ACTIVE，但背后真实原因是日志没应用完。别信状态字段表面值，直接查物理事实：

在备库执行：SELECT MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG GROUP BY APPLIED; —— 确保 APPLIED = 'YES' 对应的最大 SEQUENCE# 与主库当前 V$ARCHIVE_DEST_STATUS.ARCHIVED_THREAD# 完全一致
检查 MRP 是否真在跑：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; —— 必须返回 MRP0 + APPLYING_LOG，空行或 IDLE 都不行
确认是否实时应用：SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; —— 必须是 MANAGED REAL TIME APPLY，不是 IDLE 也不是空

DGMGRL 中 VALIDATE 失败后不能跳过，必须人工补救

VALIDATE DATABASE 'standby_db_name' 报 ORA-16175，说明 Broker 已识别出硬性不满足项。此时执行 ENABLE 或 REINSTATE 是无效的，Broker 不会重试未通过的校验点：

若 V$ARCHIVE_DEST_STATUS.STATUS 为 ERROR，先在主库执行：ALTER SYSTEM SET log_archive_dest_state_2=RESET;，再 ENABLE，最后手工触发一次归档：ALTER SYSTEM ARCHIVE LOG CURRENT;
若备库 V$DATABASE.SWITCHOVER_STATUS 是 SESSIONS ACTIVE，但 SELECT COUNT(*) FROM V$SESSION WHERE TYPE != 'BACKGROUND'; 返回 0，说明控制文件残留旧状态，需在备库执行：ALTER SYSTEM CHECKPOINT; + ALTER SYSTEM SWITCH LOGFILE; 强制刷一次检查点
禁用 FAST_START_FAILOVER：在主库查 SELECT FS_FAILOVER_STATUS FROM V$DATABASE;，若非 DISABLED，必须先 DISABLE 再重试

绕过 Broker 直接用 SQL 切换的底线条件

当 DGMGRL 卡死且反复 VALIDATE 无解时，可退到 SQL 层，但前提是已人工确认三件事全部成立：

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

备库 V$ARCHIVED_LOG 中 APPLIED = 'YES' 的最大 SEQUENCE# ≥ 主库 V$LOG.SEQUENCE#（即无 gap）
备库 V$MANAGED_STANDBY.PROCESS = 'MRP0' 且 STATUS = 'APPLYING_LOG' 持续运行超 30 秒
主库 V$DATABASE.SWITCHOVER_STATUS = 'TO STANDBY'，且 LOG_ARCHIVE_DEST_STATE_2 = 'ENABLE'

满足后，按顺序执行：
主库：ALTER DATABASE SWITCHOVER TO 'standby_db_name' VERIFY; → 成功后再执行 ALTER DATABASE SWITCHOVER TO 'standby_db_name';
备库：ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; → 然后 ALTER DATABASE OPEN;