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 回答