oracle 19c备库switchover后在dgmgrl中显示disabled是broker的默认保护行为，并非故障；因原主库变新备库后log_archive_dest_2指向已失效旧备库，broker检测归档目标不可达即自动置为disabled，需先验证v$archive_dest_status和v$managed_standby状态并确保fal_server、standby_file_management等配置正确后，再按顺序执行enable configuration和enable database。
oracle 19c备库在switchover后显示disabled状态，不是配置被“关掉”了，而是data guard broker（dgmgrl）自动将该备库的配置状态设为disabled——这是broker的默认保护行为，防止切换后旧主库（新备库）意外参与日志传输或被误选为failover目标。
为什么DGMGRL里SHOW CONFIGURATION看到备库是DISABLED
Switchover完成后，Broker会重置整个配置拓扑。原主库变成新备库后，其LOG_ARCHIVE_DEST_2指向的是“已不存在”的旧备库（逻辑上已失效），Broker检测到归档目标不可达或角色未就绪，就主动把该数据库条目标记为DISABLED。这不是错误，是Broker的防御性状态。
-
DISABLED≠ 数据库宕机或归档中断，只是Broker层面不调度它参与DG管理流程 - 真实归档和日志应用是否正常，得看
V$ARCHIVE_DEST_STATUS.STATUS和V$MANAGED_STANDBY，不是看DGMGRL输出 - 如果直接执行
ENABLE DATABASE 'orcl_stdy'失败，大概率是因为底层归档路径、FAL参数或STANDBY_FILE_MANAGEMENT还没调通
手动启用前必须确认的3个底层状态
DGMGRL的ENABLE命令本质是校验并激活归档链路。它失败时不会告诉你具体哪一环断了，得人工查清：
- 主库（现新主库）上：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;—— 必须是VALID，且ERROR为空；若为ERROR，常见是FAL_SERVER没指向新备库，或LOG_ARCHIVE_DEST_2里SERVICE名解析失败 - 新备库（原主库）上：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'RFS');—— 必须有MRP0且状态为APPLYING_LOG；若只有RFS而无MRP0，说明RECOVER MANAGED STANDBY DATABASE没启动 - 两边
STANDBY_FILE_MANAGEMENT都必须是AUTO，否则ENABLE DATABASE会静默失败（尤其RAC环境，节点间参数不一致极常见）
用DGMGRL正确启用的两步顺序
不能跳过验证直接ENABLE。Broker对状态敏感，顺序错一步就卡住：
- 先连新主库执行：
ENABLE CONFIGURATION;—— 这步激活整个DG配置，但新备库仍为DISABLED - 再单独启用新备库：
ENABLE DATABASE 'orcl_stdy';—— 此时Broker才会去检查它是否满足归档+应用双条件 - 如果第二步报
ORA-16625: cannot reach database "orcl_stdy"，别反复重试，立刻查新备库监听是否注册了GLOBAL_DBNAME=orcl_stdy_DGMGRL，这是RAC/单机混部时最常漏的静态监听项
真正麻烦的不是DISABLED状态本身，而是它背后隐藏的归档链路断裂——比如FAL_SERVER还指着旧地址，或LOG_ARCHIVE_CONFIG没及时双向更新。这些细节在alert.log里只报一句SWITCHOVER VERIFY WARNING，但足以让ENABLE永远失败。
