Oracle 将数据库还原到“较新”版本答案

【问题标题】：Oracle restore database to a "newer" versionOracle 将数据库还原到“较新”版本
【发布时间】：2011-11-26 15:24:11
【问题描述】：

是否可以测试增量备份...嗯，增量备份？ 如果可以：如何？ - 并且不使用“重复”和“备用”这两个词。

设置

在 0 级备份之后，我们将所有备份文件发送到测试平台（出于所有意图和目的而离线）并执行完全还原和恢复。我想要的是将增量备份（

最终目标是在 12 小时增量周期中将只读表空间占用的灾难恢复测试时间减少约 70% - 策略要求每周进行一次完全恢复/恢复。

如果我的 - 尚不完整 - 解决方案还远远不够，欢迎提出建议（仍然不使用“重复”或“备用”：o）。

2011 年 10 月 4 日编辑： 所以我想出了如何避免在每次测试时恢复只读表空间，这样可以节省 70% 的时间。剩下的就是弄清楚是否可以只将最新的增量备份恢复到测试台上。

需要明确的是：周日我最终会以全新的方式恢复 + 恢复所有内容，包括只读。每 12 小时我执行一次新的还原测试，它会跳过只读位，但对剩余的 30% 执行 0 级还原，然后应用增量 - 实际上是回滚到周日，然后赶上最新的增量。

我希望在周日进行一次完整恢复，并且每 12 小时仅将最新的增量备份“应用”到此恢复中，避免回滚到周日。

【问题讨论】：

好的，所以要部分回答我自己的问题。可以在我的测试数据库之上恢复新的控制文件（和 spfile），然后让 RMAN 进行恢复。在此过程中，它断言只读表空间映像“已恢复到磁盘 X”并继续恢复 0 级备份映像。到目前为止，节省了 70%！

【解决方案1】：

我不确定您的配置的备份时间、传输时间和恢复时间之间的区别，但这是我的想法。

如果您想减少恢复时间，请调查 RMAN RESTORE 命令的 CHECK READONLY 参数。听起来您可以在目标系统上保留只读数据文件的副本，而不会产生 RMAN 在还原时推送所有这些位和字节的开销。

您没有从 9i RMAN 文档中提到 RMAN RESTORE 命令的版本：

只读检查检查只读文件的标头以确保它们是最新的，然后再从恢复中忽略它们。

如果您想减少 0 级备份集的传输时间并保证只读数据文件的安全，请研究 BACKUP 命令的 SKIP READONLY 参数。

只读跳过指定应从备份集中排除只读数据文件。

如果您是偏执狂（像我一样）并且需要另一个级别的验证，您可以在双方运行您的只读数据文件的校验和，以确保您获得相同的值。

但请注意您是如何处理这种情况的 - 在真正的还原情况下是否会遵循相同的过程（无论是 CHECK READONLY 还是其他方法）？

【讨论】：

嗨，大卫。我已经得到了只读部分（正如我上面的评论应该表明的那样）。我已经稍微更新了问题以反映剩余的问题。
您是在每次还原后打开数据库还是只是检查还原是否正常？如果它坐在那里并且您恢复增量 - 您不能继续传输和恢复从源系统生成的备份集吗？
是的，目标是在生成备份集时连续传输它们。这看起来很傻，但是是的，我们在恢复后打开数据库。但如果我们不这样做，它会起作用吗？实际上我在想..我们的增量包含块更改和归档日志，所以当我们在最终增量后恢复大约 5 分钟的归档日志时，我们可能会毁掉一切。
打开似乎没那么傻——你想知道数据库是否会打开而不抱怨吗？ :) 我明白你在做什么，在应用归档日志之后，你的数据文件似乎介于之前的恢复（1 级或 0 级）和你试图应用的新的 1 级之间。不确定 RMAN 是否允许您“赶上”新创建的 Level 1。您尝试过吗？我很好奇您可能会从 RMAN 中得到哪些令人兴奋的新错误消息。我想知道它是否不会首先检查 SCN 并且不允许该操作。

【解决方案2】：

我觉得这需要回答，即使只是部分回答，所以你去吧：

恢复部分仍然打开，但使用可转移表空间解决了避免只读表空间位的问题。基本上，

我们为 3TB 的表空间执行此操作，总共花费了 30 秒。（以及 10 小时的复制时间：oP）

请注意：标记为可转移并删除表空间可能不是正确的做法，尤其是在表空间之间存在依赖关系的情况下。

【讨论】：