原主库SWITCHOVER_STATUS为NOT ALLOWED时，须先追平新主库SCN：启用闪回则FLASHBACK DATABASE至STANDBY_BECAME_PRIMARY_SCN后MOUNT；未启用则需RMAN增量备份恢复并执行ALTER DATABASE CONVERT TO PHYSICAL STANDBY。
原主库角色已变但未同步，SWITCHOVER_STATUS 显示 NOT ALLOWED 怎么办
这是最常见卡点：原主库重启后仍是 PRIMARY 角色，但新主库已开始生成新归档，它和新主库之间出现 gap，导致 SWITCHOVER_STATUS 为 NOT ALLOWED。不能直接执行 ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY。
必须先让原主库“追上”新主库的 SCN 或归档序列号，否则 Broker 或手动 SQL 都会拒绝切换。
- 在新主库查出切换发生时的精确 SCN：
SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE; - 在原主库（当前仍为
PRIMARY）执行闪回（前提是已启用FLASHBACK DATABASE且DB_RECOVERY_FILE_DEST有足够空间）：FLASHBACK DATABASE TO SCN <scn_value>;</scn_value> - 闪回后立即
SHUTDOWN IMMEDIATE，再STARTUP MOUNT - 此时再查
SWITCHOVER_STATUS，应变为TO STANDBY，才可继续下一步
用 sys_rewind？不，Oracle 没这命令——别和 KingbaseES 混了
看到 sys_rewind 就想到 KingbaseES，但 Oracle 没这个工具。强行套用会浪费大量时间排查不存在的命令。Oracle 的等效机制是 FLASHBACK DATABASE 或完整重建备库。
如果没开闪回，或 STANDBY_BECAME_PRIMARY_SCN 对应的 flashback log 已被覆盖，就只剩一条路：重搭。
- 从新主库做一次 RMAN 增量备份（基于当前 SCN）：
BACKUP INCREMENTAL FROM SCN <scn_value> DATABASE FORMAT '/path/incr_%U';</scn_value> - 在原主库主机恢复控制文件 + 数据文件 + 归档日志（注意路径映射）
-
RECOVER DATABASE后ALTER DATABASE CONVERT TO PHYSICAL STANDBY - 启动日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
ALTER DATABASE CONVERT TO PHYSICAL STANDBY 执行失败的典型原因
这条命令看似简单，实际依赖多个隐含前提。失败时错误信息常模糊，比如 ORA-16625: cannot reach database 或直接报权限不足，其实多是配置残留。
- 确认
LOG_ARCHIVE_CONFIG已更新为新主库的DB_UNIQUE_NAME，且包含双方：'DG_CONFIG=(new_primary_db,old_primary_db)' -
FAL_SERVER必须指向新主库的 TNS 别名，不是旧主库地址 -
LOG_ARCHIVE_DEST_2要指向新主库，并设VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)；同时确保LOG_ARCHIVE_DEST_STATE_2=ENABLE - 检查
v$archive_dest_status中目标地址状态是否为VALID，GAP_STATUS是否为NO GAP
启动日志应用后 MRP 进程不拉起或卡在 WAIT_FOR_GAP
即使 ALTER DATABASE RECOVER... 成功返回，v$managed_standby 里可能看不到 MRP，或它一直停在 WAIT_FOR_GAP ——说明归档传输链路不通，或归档文件根本没传过来。
- 先确认新主库的
ARCH进程是否活跃：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'ARCH'; - 查新主库上归档是否成功发往原主库：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; - 若
ERROR非空，重点检查网络连通性、监听是否启动、tnsnames.ora 中对应别名解析是否正确 - 临时测试：在新主库手工
ALTER SYSTEM ARCHIVE LOG CURRENT;，然后立刻在原主库查v$archived_log看是否有新记录
真正难的不是命令怎么敲，而是每一步背后的状态是否真实对齐。一个 GAP_STATUS 是 NO GAP，不代表归档已到达；一个 MRP 显示 APPLYING_LOG，也不代表数据已一致——得盯住 v$dataguard_stats 里的 apply lag 降到 0 秒才算落地。
