Oracle - 减少从一个数据库迁移到另一个数据库时的停机时间
假设您有一个在生产备份上运行的 Oracle 数据库。您想要回到生产环境（目前没有数据）。导出、导入、索引和运行统计信息收集需要 4 小时。因此，如果您停止生产备份，那么在迁移回生产时您会停机 4 个小时。导入时间较长的部分原因是其中有大量历史数据并不立即用于操作。您如何将数据从生产备份迁移到生产以最大程度地减少停机时间，以免停机 4 小时？
Let's say you have an Oracle database running on production-backup. You want to move back to production (which has no data at this time). To export, import, index, and run statistics collection takes 4 hours. So, if you stop production-backup, you are down 4 hours while you migrate back to production. Part of the long import time is that there is a bunch of historical data in there not immediately needed for operations. How would you migrate your data from production-backup to production to minimize downtime so that you aren't down for 4 hours?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首选选项是使用 Oracle Data Guard。首先，您将实例化新的生产数据库作为当前数据库的物理备用数据库。然后，当您想要迁移到新数据库时，只需执行从主数据库到备用数据库的切换即可。您可能希望通过在备份服务器上实例化新生产数据库的物理备用数据库来进行后续操作。
如果您没有企业版，您可以手动执行基本相同的操作。假设数据库处于 ARCHIVELOG 模式，您可以在当前生产数据库运行时运行其备份，将该备份恢复到生产服务器，然后应用当前生产数据库中的存档日志以使备份接近同步。当您准备好进行切换时，您需要关闭当前的生产数据库，将最后的存档日志复制到备份，应用存档日志，然后将备份作为新的生产数据库启动。
The preferred option would be to use Oracle Data Guard. First, you would instantiate the new production database as a physical standby for the current database. Then, when you wanted to move to the new database, you'd simply issue a switchover from the primary to the standby. You may want to follow that up by instantiating a physical standby for the new production database on the backup server.
If you don't have the enterprise edition, you can do essentially the same thing manually. Assuming the database is in ARCHIVELOG mode, you can run a backup of the current production database while it is up, restore that backup to the production server, and then apply archived logs from the current production database to get the backup close to synchronized. When you're ready to do the switchover, you'd need to shut down the current production database, copy the last archived logs to the backup, apply the archived logs, and then bring up the backup as the new production database.