在Oracle中使用NOLOGGING时,比如说插入新记录.我的数据库是否能够从断电中正常恢复?如果它在插入期间随机下降.
我是否正确说明UNDO日志将用于此类恢复...而不是REDO日志使用,如果主数据文件已被物理损坏,则可用于恢复.
在我看来,你在这里混淆了一些概念.
首先,我们来谈谈实例恢复.实例恢复是数据库崩溃后发生的事情,无论它是否被终止,服务器是否已关闭等.在实例启动时,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,实例恢复和介质恢复的想法.
归档时间: |
|
查看次数: |
487 次 |
最近记录: |