验证主备同步状态是切换前的硬性前提，关键在于主库最新日志是否已在备库应用，需通过v$archived_log确认sequence#存在且applied为YES或IN-MEMORY，否则切换将导致数据丢失。
验证主备同步状态是切换前的硬性前提
没确认同步就切，等于拿生产环境赌一把。关键不是“有没有同步”，而是“最新日志是否已应用”。v$archived_log里查sequence#和applied字段必须同时满足：主库最新sequence#在备库存在，且对应记录的applied值为YES（或IN-MEMORY表示正在实时应用）。NO说明归档还没被应用，此时切换会导致数据丢失。
常见错误现象：SELECT sequence#, applied FROM v$archived_log ORDER BY sequence# DESC返回多条记录，但最新几条applied = NO；或者主备sequence#最大值差 1–2，但备库applied始终卡在旧值。这通常意味着MRP（Managed Recovery Process）没启动，或网络/归档路径配置异常。
- 必须在备库执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT，否则恢复进程不运行 - 检查
v$managed_standby中PROCESS列是否有MRP0，状态是否为APPLYING_LOG - 如果用Broker管理，
SHOW CONFIGURATION输出里不能出现WARNING或ERROR
用switchover做计划内切换测试，别直接failover
容灾演练不是灾难发生，不该走failover流程。switchover才是验证链路完整性的正确方式：它要求主备双向通信正常、角色可逆、状态校验通过。一旦switchover成功，说明Broker配置、监听、密码文件、归档传输全部就绪。
实操时注意顺序不可跳步：
- 主库先查：
SELECT switchover_status FROM v$database，必须返回TO STANDBY或SESSIONS ACTIVE（后者需加WITH SESSION SHUTDOWN） - 备库查：
SELECT switchover_status FROM v$database，必须是TO PRIMARY，否则说明同步中断或Broker未同步元数据 - 主库执行
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY后，必须SHUTDOWN IMMEDIATE再STARTUP MOUNT，不能跳过mount状态 - 新主库（原备库）
STARTUP后，立刻查SELECT open_mode, database_role FROM v$database，确认是OPEN / PRIMARY
Snapshot Standby用于读写类容灾测试，但有三个强约束
想在备库上跑真实业务脚本、验证应用兼容性？CONVERT TO SNAPSHOT STANDBY是唯一安全路径。但它不是“打开就能用”的功能，而是依赖三个刚性条件：
- 闪回数据库必须启用：
SELECT flashback_on FROM v$database返回YES，且数据库处于MOUNT状态才能执行ALTER DATABASE FLASHBACK ON - FRA空间剩余≥20%：
SHOW PARAMETER db_recovery_file_dest_size和SELECT * FROM V$RECOVERY_FILE_DEST一起看，空间不足会导致CONVERT命令挂起或报ORA-38701 - 主备Patch RU版本必须完全一致：包括补丁编号（
opatch lsinventory输出中的Patch ID），仅版本号相同（如都是19.19）但补丁ID不同，会在ALTER DATABASE OPEN后卡住PDB启动，日志里刷WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!
转换命令顺序严格：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL → SHUTDOWN IMMEDIATE → STARTUP MOUNT → ALTER DATABASE CONVERT TO SNAPSHOT STANDBY → ALTER DATABASE OPEN。漏掉CANCEL或SHUTDOWN，后续CONVERT会报ORA-01507。
切换后必须验证应用层连通性和数据一致性
数据库角色变了，不代表业务能用。很多团队只验证SELECT COUNT(*)，结果上线后发现序列号错乱、LOB字段读取失败、甚至连接池连不上新VIP。
真实验证点要覆盖三层：
- 网络层：应用服务器
tnsping新主库服务名是否通；sqlplus /@new_primary_service能否直连 - 数据层：在新主库执行
SELECT MAX(id) FROM test_table，在原主库（现备库）查同一表，确认数值一致；重点查含SEQUENCE、SYSDATE、XMLTYPE字段的表 - 应用层：触发一笔真实交易（如下单、支付回调），检查订单状态、库存扣减、消息队列投递是否闭环
最易被忽略的是FRA路径权限和监听配置——切换后新主库的listener.ora可能还指向旧IP，或db_recovery_file_dest目录属主没同步改，导致归档写入失败，后续再切回去就断链。每次切换后，务必在新主库执行ARCHIVE LOG LIST和SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS != 'VALID'。
