备库SWITCHOVER_STATUS为SWITCHOVER LATENT时，需立即执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION触发日志应用，而非等待；成功后SELECT SWITCHOVER_STATUS将秒变TO PRIMARY。
备库 SWITCHOVER_STATUS 显示 SWITCHOVER LATENT 怎么办
这不是等待就能解决的状态，本质是备库日志应用滞后，还没追平主库。直接执行切换会报 ORA-16139: media recovery required。
关键动作是手动触发日志应用，而不是等自动恢复：
- 在备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;（注意不是CANCEL） - 立即查
SELECT SWITCHOVER_STATUS FROM V$DATABASE;—— 多数情况下秒变TO PRIMARY - 若仍不生效，检查
V$ARCHIVE_GAP是否有缺口；有缺口就需从主库拷归档并REGISTER - 别忽略
LOG_ARCHIVE_DEST_n状态，ERROR列非空说明传输链路断了，得先修网络或参数
Failover 后旧主库用 RMAN 恢复为备库的关键 SCN 怎么取
必须用新主库（原备库）上的 STANDBY_BECAME_PRIMARY_SCN，不是随便选个备份时间点。
这个 SCN 是故障转移发生的精确临界点，错一点就会导致控制文件与数据文件不匹配：
- 在新主库上运行：
SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE; - RMAN 中的
SET UNTIL SCN必须设为该值 +1（不是等于，也不是减 1） - 如果旧主库已 shutdown abort，恢复前必须先
STARTUP MOUNT，不能直接OPEN - 恢复完成后不要急着打开，先
ALTER DATABASE CONVERT TO PHYSICAL STANDBY，否则后续无法注册日志
Failover 后重做传输没起来，LOG_ARCHIVE_DEST_STATE_n 为什么还是 DISABLE
Failover 不会自动重置归档目的地状态，旧主库变成新备库后，它的归档目标仍是“指向自己”或已失效地址。
常见误操作是只改 LOG_ARCHIVE_DEST_n 路径，却忘了开开关：
- 先查现状：
SELECT DEST_ID, DEST_NAME, STATUS, DESTINATION, ERROR FROM V$ARCHIVE_DEST_STATUS; - 确认目标
DEST_ID对应的STATUS是INACTIVE或DEFERRED，而非VALID - 启用它：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_<n>=ENABLE;</n>（<n></n>替换为实际 ID） - 强制切一次日志：
ALTER SYSTEM SWITCH LOGFILE;，再查ERROR列是否清空 - 一主多备环境下，新备库上还要检查是否误启用了发往其他备库的
LOG_ARCHIVE_DEST_n，得SET LOG_ARCHIVE_DEST_<n>=''</n>清空
ROSE HA 切换节点后 DG 失效，为什么 RMAN 备份反而让恢复更难
因为 HA 节点切换后，新节点的 spfile 里 db_unique_name、log_archive_config 等参数可能没同步更新，而 RMAN 备份又清掉了归档日志。
结果就是：旧归档没了，新归档路径不对，备库收不到任何日志：
- 别急着跑 RMAN 全库备份，先停掉清理脚本，保留所有归档（尤其
find ... -mtime +7这类自动清理） - 对比新旧节点
spfile差异，重点核对：db_unique_name、log_archive_dest_2、fal_client/fal_server - 如果归档已丢失，只能退回到用
STANDBY_BECAME_PRIMARY_SCN做不完全恢复，丢部分事务 - 恢复后首次
ALTER DATABASE OPEN READ ONLY是必须步骤，它会校验控制文件与数据字典一致性，跳过这步后续日志应用必报错
CONVERT TO PHYSICAL STANDBY，或者做了但没 SHUTDOWN IMMEDIATE 再 STARTUP MOUNT —— 这两个步骤缺一不可，否则控制文件仍按主库逻辑工作，后续所有日志注册和应用都会失败。 
