在Oracle中使用NOLOGGING时，比如说插入新记录。我的数据库是否能够从断电中正常恢复？如果它在插入期间随机下降。
我是否正确地指出UNDO日志将用于此类恢复...而不是REDO日志使用，如果主数据文件已被物理损坏，则可用于恢复。
答案 0 :(得分：5)
在我看来，你在这里混淆了一些概念。
首先，我们来谈谈实例恢复。实例恢复是数据库崩溃后发生的事情，无论它是否被终止，服务器是否已关闭等。在实例启动时，Oracle将从重做日志中读取数据并前滚，将所有挂起的更改写入数据文件。接下来，它将读取undo，确定哪些事务未提交，并使用undo中的数据来回滚在崩溃时未提交的任何更改。通过这种方式，Oracle保证恢复到最后一次提交的事务。
现在，关于直接加载和NOLOGGING。值得注意的是，NOLOGGING 仅 对直接加载有效。这意味着更新和删除从不 NOLOGGING，并且如果您指定APPEND提示，INSERT只是nologging。
重要的是要了解当您进行直接加载时，您实际上是将数据“直接加载”到数据文件中。因此，无需担心实例恢复等问题。当您进行NOLOGGING直接加载时，数据仍会直接写入数据文件。
它是这样的。你直接加载（现在，让我们留下NOLOGGING的问题），并将数据直接加载到数据文件中。发生的方式是，Oracle将从高水位线（HWM）上方分配存储，并直接格式化并加载这些全新的块。在进行块分配时，描述空间分配的那些数据字典更新将被写入并由redo保护。然后，当您的事务提交时，更改将成为永久更改。
现在，如果实例崩溃，则提交事务（在这种情况下，数据位于数据文件中，数据字典反映了已分配的新扩展区），或者未提交，以及表看起来和直接负载开始之前完全一样。因此，同样可以恢复包括上次提交的事务在内的数据。
现在，NOLOGGING。是否记录直接加载与实例恢复无关。如果媒体失败和媒体恢复，它将仅发挥作用。
如果您遇到媒体故障，则需要从备份中恢复。因此，您将恢复损坏的数据文件，然后从存档的重做日志中应用重做，以“回放”从备份时间到当前时间点发生的事务。只要记录了所有更改，这不是问题，因为重做日志中存在所有数据。但是，如果在NOLOGGING直接加载后出现介质故障，会发生什么？
好吧，当重做应用于使用NOLOGGING加载的段时，重做时所需的数据不。因此，我提到的那些数据字典事务创建了加载数据的新扩展区，这些是重做的，但没有任何东西可以填充这些块。因此，范围被分配给段，但随后也被标记为无效。因此，如果/当您尝试从表中选择并点击那些无效块时，您将使用NOLOGGING选项加载ORA-26040“数据”。这是Oracle让您知道通过NOLOGGING操作恢复导致数据损坏。
那么，该怎么办？好吧，首先，每次使用NOLOGGING加载数据时，请确保在必要时可以重新运行加载。因此，如果您在加载过程中遇到实例故障，则可以重新启动加载，或者如果在NOLOGGING加载和下次备份之间出现介质故障，则可以重新运行加载。
请注意，在NOLOGGING直接加载的情况下，在您下次备份包含具有直接加载的段的数据文件/表空间之前，您只会遇到数据丢失。一旦受到备份保护，您就安全了。
希望这有助于澄清有关直接加载，NOLOGGING，实例恢复和媒体恢复的想法。
答案 1 :(得分：1)
如果您使用NOLOGGING，则不关心数据。除了常规数据库恢复过程之外，其他过程应该可以恢复Nologging操作。很多时候，恢复将毫无问题地发生。问题是当存储器出现电源故障时。在这种情况下，您可能最终破坏在线重做 - 这是活动的 - 并且因此也存在损坏的撤销段的问题。
所以，特别是在你的情况下：我不会赌它。 是的，大部分的恢复都是通过读取撤消来完成的，因为你所描述的情况可能会被卡住。这是最难恢复的问题之一。
答案 2 :(得分：0)
为了100％符合ACID标准，DBMS需要可序列化，即使在主要供应商中也是如此。要进行可序列化的读取，写入和范围锁定需要在事务结束时释放。 Oracle中没有读锁定，因此Oracle不符合100％ACID标准。