必须先停日志应用再执行convert命令，否则报ORA-38784或ORA-01153；备库须MOUNT状态且非READ ONLY WITH APPLY；FRA必须配置但无需开启Flashback；转换后需显式open才能读写；切回物理备库前须确保归档日志完整。
必须先停掉日志应用，再执行 alter database convert to snapshot standby，否则会报 ora-38784 或 ora-01153 错误。
备库必须处于 MOUNT 状态且日志应用已取消
物理备库在转换前不能是 READ ONLY WITH APPLY 状态，哪怕只差一秒的延迟也不行。常见错误现象是执行 alter database convert to snapshot standby 时直接报错：ORA-38784: Cannot create restore point... 或 ORA-01153: an incompatible media recovery is active。
正确操作顺序是：
- 先执行
alter database recover managed standby database cancel; - 确认当前状态：查
v$database的open_mode必须是MOUNTED，database_role是PHYSICAL STANDBY - 如果已是
OPEN READ ONLY，需先shutdown immediate再startup mount
闪回恢复区（FRA）必须已配置，但无需开启 Flashback Database
DB_RECOVERY_FILE_DEST 和 DB_RECOVERY_FILE_DEST_SIZE 是硬性要求，否则转换会失败；但 FLASHBACK_ON = NO 完全不影响 Snapshot Standby 功能——Oracle 内部会自动创建 guaranteed restore point，不依赖你手动开闪回。
检查方式：
-
show parameter db_recovery_file_dest—— 路径和大小都得非空 -
select FLASHBACK_ON from v$database;—— 返回NO没问题 - 注意：RAC 环境下所有节点都要确保 FRA 配置一致，且至少一个节点启动到
MOUNT后再转换
转换后需显式 alter database open 才能读写
alter database convert to snapshot standby 只改角色和状态，数据库仍停留在 MOUNTED，此时还不能连入或建表。必须紧接着执行 alter database open，才能进入 READ WRITE 模式。
验证是否生效：
-
select database_role, open_mode from v$database;应返回SNAPSHOT STANDBY和READ WRITE - 此时可正常建表、跑 SQL、压测——所有变更在切回物理备库时自动丢弃
- 主库日志仍持续传输并归档到备库（
ARCHIVED_LOG会增长），只是不应用（MRP 进程停止）
压力测试完成后切回物理备库的关键点
不是简单重启或执行反向命令就行。真正容易被忽略的是：切回前必须确保主库传来的所有归档日志已在备库本地可用，否则恢复过程会卡在“等待缺失日志”上。
推荐步骤：
- 先停掉测试负载，执行
shutdown immediate - 启动到
MOUNT状态：startup mount - 执行
alter database convert to physical standby;（此步会自动删除内部 restore point） - 再启动日志应用：
alter database recover managed standby database using current logfile disconnect; - 最后检查
v$archive_gap是否为空，v$managed_standby中 MRP 进程是否 RUNNING
如果主库在 Snapshot 期间产生了大量日志，而备库归档目录空间不足或网络中断过，切回时可能需要手动拷贝缺失归档或使用增量备份恢复——这点在生产环境压测前必须预估好归档吞吐和存储余量。
