Oracle 11g物理备库转Snapshot Standby压力测试指南

先说几个核心判断：将物理备库转换为 Snapshot Standby 的流程本身不算复杂，但实际操作中踩坑的人确实不少。大部分报错其实都源于两个常见问题——操作顺序搞错、前置条件未严格满足。本文将完整拆解整个转换流程，并重点指出最容易出错的节点，帮助读者顺利避坑。

第一步，务必先停止日志应用。这是铁律，没有商量余地。如果直接在日志应用尚未取消的状态下执行 alter database convert to snapshot standby，系统会毫不客气地抛出ORA-38784或ORA-01153错误。别指望绕过去，Oracle 对此绝不通融。

物理备库转换 Snapshot Standby：必须处于 MOUNT 状态且日志应用已取消

这里有一个容易被忽略的细节：物理备库在转换之前，不能处于 READ ONLY WITH APPLY 状态。哪怕日志应用只差一秒的延迟，系统都会报错。常见错误提示包括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、压力测试都没有问题。所有在 Snapshot Standby 期间的变更，切换回物理备库时都会自动丢弃，不用担心污染主库数据
• 注意一个细节：主库的日志仍然持续传输并归档到备库（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 期间产生了大量归档日志，而备库的归档目录空间不足，或者网络出现中断，切回时就可能面临手动拷贝缺失归档或使用增量备份恢复的尴尬局面。这一点在生产环境进行压测前，务必提前评估好归档吞吐量和存储余量，不要等问题发生了再补救。