Failover后新主库不再是备库，控制文件中无备库元数据，OPEN READ ONLY被拒绝；V$DATABASE.OPEN_MODE为READ WRITE，非ADG所需的READ ONLY WITH APPLY；无法退回standby模式，须按新主库重建DG环境。
Failover后备库已不存在，所谓“备库”变成新主库
Failover 的本质是物理备库升主、原主库角色被彻底覆盖。执行完 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE 和 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY（或隐式完成）后，数据库角色永久变为 PRIMARY，控制文件中不再保留任何“曾为备库”的元数据。此时再试图对它执行 ALTER DATABASE OPEN READ ONLY，Oracle 会直接拒绝——因为这不是一个 standby 数据库，而是一个标准的 primary 实例，OPEN READ ONLY 对 primary 无效（除非是 snapshot standby，但那需要提前配置）。
ADG许可和OPEN_MODE状态不匹配
即使误以为还能当备库用，也常卡在许可和状态层面：
-
V$DATABASE.OPEN_MODE返回READ WRITE，不是READ ONLY WITH APPLY—— 后者才是 ADG 正常工作的标志，只可能出现在未 failover 的、持续应用日志的物理备库上 - Failover 后的新主库默认不启用 ADG 功能；它没有 MRP 进程，也不需要“边读边应用”，所以
ALTER DATABASE OPEN READ ONLY不会启动日志应用，只会报ORA-16004: backup database requires recovery或静默失败 - 没买 ADG 许可？那更不可能：ADG 是 Oracle 的独立选项，Failover 不会自动激活它，也不会继承原备库的许可状态
想临时只读？只能靠应用层或数据库级限制
Failover 完成后，数据库已是功能完整的 primary，无法退回 standby 模式。若业务真有“只读验证”需求，可行路径只有两条：
- 用
ALTER SYSTEM ENABLE RESTRICTED SESSION+REVOKE CREATE SESSION FROM PUBLIC等方式手动锁死写权限，再授给特定用户——但这不是真正的只读模式，只是权限控制 - 如果提前建了 guaranteed restore point，且 Failover 前已开启
FLASHBACK DATABASE，可先SHUTDOWN IMMEDIATE→STARTUP MOUNT→FLASHBACK DATABASE TO RESTORE POINT xxx→ALTER DATABASE OPEN RESETLOGS，再尝试转为 snapshot standby（需ALTER DATABASE CONVERT TO SNAPSHOT STANDBY）。但该路径极脆弱：依赖闪回日志完整、控制文件未损坏、且不能跨 resetlogs 边界
最常被忽略的判断点：别把新主库当备库看
很多人查 V$MANAGED_STANDBY 发现没有 MRP 进程，就去重启日志应用，结果报 ORA-01153: an incompatible media recovery is active —— 因为 recovery 已被彻底终止，数据库已脱离 DG 上下文。Failover 不是暂停，是终结。后续所有操作都应基于“这是一台新主库”的前提展开，比如重建原主库为新备库、重配归档目标、重新注册服务名等。把 Failover 后的实例还当成“可读写的备库”来处理，是绝大多数问题的起点。
