根本原因是日志传输和应用链路未闭环，即主库已发、备库已收、备库已应用三步未全部验证完成；Switchover前须确认SWITCHOVER_STATUS为TO STANDBY而非SWITCHOVER LATENT，否则会丢事务。
切换后数据丢失，根本原因不是操作错，而是日志传输和应用链路没真正闭环。 Switchover 本身不丢数据，但前提是你确认了“主库已发、备库已收、备库已应用”这三步全部完成。Failover 更危险——它默认只管“备库收到多少”，不管“收到的有没有被应用”。下面直说关键动作点。
Switchover 前必须验证 SWITCHOVER_STATUS 是 TO STANDBY 而非 SWITCHOVER LATENT
状态为 SWITCHOVER LATENT 意味着备库还没追平主库，强行切换会丢事务。这不是等出来的，是查出来的：
- 在备库执行
SELECT DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE;，若返回PHYSICAL STANDBY+SWITCHOVER LATENT，立刻停手 - 查
V$ARCHIVED_LOG确认最大SEQUENCE#是否与主库一致；不一致就说明归档没传完 - 查
V$MANAGED_STANDBY中PROCESS为MRP0的状态是否为APPLYING_LOG，且SEQ#和BLOCK#在持续递增 - 别信
RECOVERY_MODE = MANAGED REAL TIME APPLY—— 它只表示“正在尝试实时应用”，不代表已追上
Failover 前必须确认备库是否启用 AFFIRM 且日志已落盘
最大可用模式（Maximum Availability）下，LOG_ARCHIVE_DEST_2 若只配 SERVICE=standby SYNC，主库可能已向客户端返回“提交成功”，但 redo 还卡在备库内存或 SRL 缓冲区里。故障一来，这部分事务就没了。
- 必须显式加
AFFIRM：例如LOG_ARCHIVE_DEST_2='SERVICE=standby AFFIRM SYNC NET_TIMEOUT=30' - 检查是否生效：
SELECT DEST_NAME, TRANSMISSION_MODE, AFFIRM, SYNC_LEVEL FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;，输出中AFFIRM列必须为YES，SYNC_LEVEL为SYNC -
NET_TIMEOUT=30是底线值，低于它会导致网络抖动时自动降级为异步，失去同步保障
切换后立即检查 V$DATAGUARD_STATS 和 V$ARCHIVE_DEST_STATUS
切完不是万事大吉。新主库启动后，原主库（现备库）的日志传输是否重建？有没有卡在 ERROR 或 DEFERRED？这些不查，下次再切就又踩坑。
- 在新主库上运行：
SELECT DEST_ID, STATUS, ERROR, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID IN (1,2); - 重点关注
GAP_STATUS：若为RESOLVING或NO GAP才算安全；UNKNOWN往往意味着归档目标不可达 - 查延迟：
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME IN ('transport lag', 'apply lag');，两个值都应为+00 00:00:00或极小（如+00 00:00:01）
最容易被忽略的是：STANDBY_FILE_MANAGEMENT=AUTO 必须在备库启用，否则新增表空间或数据文件时，备库不会自动创建对应文件，后续切换过去会直接报 ORA-01157。这个参数不是“可选优化项”，是切换链路完整的硬性前提。
