Oracle 19c主备切换后原主库未降级，因ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY执行失败导致角色未更新；需用Flashback回退至切换前SCN再手动转换，或从新主库重建控制文件恢复备库身份。
oracle 19c 主备切换后原主库没变成备库，不是配置漏了，而是它根本没进“降级流程”——alter database commit to switchover to physical standby 执行失败或被跳过，导致控制文件里角色没更新，数据库还卡在 open 状态，自然无法启动 mrp 进程应用日志。flashback 不是“修复手段”，而是兜底补救：当原主库已误开、归档断裂、scn 脱节，又不想重搭 dg 时，用 flashback 回退到 switchover 前的 scn，再手动走一遍降级流程，才能让它重新成为可用备库。
Switchover 后原主库仍为 PRIMARY 的典型现象
执行完 ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 后，检查 v$database 发现：DATABASE_ROLE 仍是 PRIMARY，OPEN_MODE 是 READ WRITE，SWITCHOVER_STATUS 变成 FAILED DESTINATION 或直接报错 ORA-01109: database not open（因强制 shutdown 导致）。这不是“没生效”，而是命令中途退出或被阻塞，比如：
- 存在活跃会话未被
WITH SESSION SHUTDOWN清掉，语句挂起超时自动回滚 -
log_archive_dest_2指向的 service 不可达，主库发不出 End of Redo 标记 - 备库还没收到并确认最后一批归档，主库就强行 commit，触发内部校验失败
- 使用了
DBMS_DATAGUARD.SWITCHOVER_STATUS查询但没等状态变为TO STANDBY就执行下一步
为什么不能直接 ALTER DATABASE MOUNT + RECOVER？
原主库如果已经以 OPEN 模式运行过哪怕 1 秒，它的数据文件 SCN 就会向前推进，而备库的 SCN 停在 Switchover 切换点。此时直接 SHUTDOWN IMMEDIATE → STARTUP MOUNT → RECOVER MANAGED STANDBY DATABASE 会立刻报 ORA-01194: file 1 needs more recovery to be consistent。因为：
- 控制文件里记录的 checkpoint SCN 高于备库当前能应用的归档终点
- 没有 Flashback 日志，无法把数据文件倒回到 Switchover 前那个一致 SCN 点
- 强行用备份+归档恢复成本高、耗时长，且需停业务
用 Flashback 把原主库拉回 Switchover 前状态
前提：原主库开启 FLASHBACK ON，且 DB_RECOVERY_FILE_DEST_SIZE 足够保留 Switchover 前至少 1 小时的 flashback logs。操作链必须严格按顺序执行：
- 立即
SHUTDOWN IMMEDIATE原主库，避免 SCN 继续漂移 -
STARTUP MOUNT，确认v$database.flashback_on = 'YES' - 查出 Switchover 前的 SCN：
SELECT CURRENT_SCN FROM V$DATABASE在切换前应已记录；若没记，可从备库查SELECT STANDBY_BECAME_PRIMARY_SCN FROM V$DATABASE（19c 新增字段），该值即为主库发出 End of Redo 时的 SCN - 执行
FLASHBACK DATABASE TO SCN <scn_value>，完成后ALTER DATABASE CONVERT TO PHYSICAL STANDBY（注意不是SWITCHOVER，此时角色未变，需显式转换） -
SHUTDOWN IMMEDIATE→STARTUP MOUNT→ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
比 Flashback 更轻量的替代方案：从备库拉控制文件重建
如果原主库 Flashback 日志不足或已关闭，别硬扛。更稳的做法是放弃本地控制文件，直接从当前主库（原备库）拉一份新控制文件过来：
- 在新主库执行：
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl'; - scp 到原主库服务器，替换原有控制文件（确保数据库已 shutdown）
- 启动到
MOUNT，此时v$database.database_role自动变成PHYSICAL STANDBY - 检查
v$datafile和v$logfile路径是否匹配本地实际位置，不匹配就ALTER DATABASE RENAME FILE - 启用日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
这个方法绕开了所有 SCN 校验和角色转换逻辑，本质是“重置身份”。但它要求原主库的数据文件本身没被写坏——也就是 Switchover 失败后没人动过它。一旦有人执行过 OPEN 或 DML，就必须用 Flashback 或备份恢复，否则数据块结构会不一致。
