2

在 Oracle 中使用 NOLOGGING 时,比如说插入新记录。我的数据库能否从停电中正常恢复?如果它在插入过程中随机下降。

我是否正确地说 UNDO 日志将用于此类恢复......而不是 REDO 日志使用情况,如果主要数据文件物理损坏,则用于恢复。

4

3 回答 3

5

在我看来,您在这里混淆了一些概念。

首先,我们来谈谈实例恢复。实例恢复是数据库崩溃后发生的事情,无论是被杀死、服务器宕机等。在实例启动时,Oracle 将从重做日志中读取数据并前滚,将所有待处理的更改写入数据文件。接下来,它将读取 undo,确定哪些事务未提交,并使用 undo 中的数据回滚到崩溃时尚未提交的任何更改。通过这种方式,Oracle 保证已经恢复到最后提交的事务。

现在,至于直接加载和NOLOGGING。需要注意的是,NOLOGGING仅对直接加载有效。这意味着更新和删除永远不会NOLOGGING,并且只有在您指定 APPEND 提示时,INSERT 才不会记录。

重要的是要了解,当您进行直接加载时,您实际上是将数据“直接加载”到数据文件中。因此,无需担心实例恢复等问题。当您执行 NOLOGGING 直接加载时,数据仍会直接写入数据文件。

它是这样的。您执行直接加载(暂时先搁置 NOLOGGING 问题),然后将数据直接加载到数据文件中。发生的方式是,Oracle 将从高水位线 (HWM) 之上分配存储,并直接格式化和加载这些全新的块。当进行块分配时,那些描述空间分配的数据字典更新被写入并受重做保护。然后,当您的事务提交时,更改将成为永久性的。

现在,在实例崩溃的情况下,事务要么已提交(在这种情况下,数据在数据文件中,并且数据字典反映了已分配的新范围),要么没有提交,并且表看起来完全一样它在直接加载开始之前发生了。因此,再次恢复直到并包括最后提交的事务的数据。

现在,NOLOGGING。是否记录直接加载与实例恢复的目的无关。它只会在媒体故障和媒体恢复的情况下发挥作用。

如果您遇到媒体故障,则需要从备份中恢复。因此,您将恢复损坏的数据文件,然后从归档的重做日志中应用重做,以“回放”从备份时间到当前时间点发生的事务。只要记录了所有更改,这不是问题,因为所有数据都在重做日志中。但是,如果在 NOLOGGING 直接加载之后发生介质故障,会发生什么情况?

好吧,当重做应用到使用 NOLOGGING 加载的段时,所需的数据不在重做中。因此,我提到的那些数据字典事务创建了加载数据的新范围,这些事务在重做中,但没有填充这些块。因此,扩展区被分配给段,但随后也被标记为无效。因此,如果/当您尝试从表中选择并点击那些无效块时,您将得到 ORA-26040“数据已使用 NOLOGGING 选项加载”。这是 Oracle 通知您通过 NOLOGGING 操作恢复导致数据损坏。

那么该怎么办?好吧,首先,每当您使用 NOLOGGING 加载数据时,请确保您可以在必要时重新运行加载。因此,如果您在加载期间确实遇到了实例故障,您可以重新启动加载,或者如果您在 NOLOGGING 加载和下一次备份之间遇到了媒体故障,您可以重新运行加载。

请注意,在 NOLOGGING 直接加载的情况下,只有在下次备份包含直接加载的段的数据文件/表空间之前,您才会面临数据丢失。一旦受到备份保护,您就安全了。

希望这有助于澄清有关直接加载、NOLOGGING、实例恢复和媒体恢复的想法。

于 2012-03-30T12:29:20.460 回答
1

如果您使用 NOLOGGING,您就不会关心数据。除常规数据库恢复过程外,不应使用其他过程恢复无日志记录操作。很多时候,恢复将毫无问题地发生。问题是当您的存储出现电源故障时。在这种情况下,您最终可能会破坏在线重做 - 这是活动的 - 并且因此也会出现损坏的撤消段的问题。

所以,特别是在你的情况下:我不会打赌。是的,大部分恢复将通过读取撤消来完成,这可能会因为您描述的情况而卡住。这是最难恢复的问题之一。

于 2012-03-29T20:25:22.717 回答
0

为了 100% ACID 兼容,DBMS 需要可序列化,即使在主要供应商中也很少见。要成为可序列化的读、写和范围锁,需要在事务结束时释放。Oracle 中没有读锁,因此 Oracle 不是 100% 兼容 ACID。

于 2015-06-03T12:28:35.120 回答