第一章 Oracle恢复内部原理（简介）

Oracle 7 v7.2 恢复大纲


作者：Andrea Borr  & Bill Bridge


版本：1                May 3, 1995


摘要


本文概述了Oracle 7.2版本如何进行数据库恢复。本文读者应当熟悉Oracle 7.2的管理指南。相比于管理指南，本文目的是为了更详细描述Oracle恢复用到的算法、数据结构以及一些技术细节。



一、简介

Oracle数据库提供了下列两类失败模式下的数据库恢复：


1.  实例失败：丢失了Oracle数据缓存中的数据或者内存中的数据


2.  介质失败：丢失了数据库文件



   上面两种模式的任一种失败情景，在恢复的时候想要保证数据库一致性，都有一些前提条件必须满足。


   虽然恢复的过程有一些共同点，但前提条件的差异使得恢复的执行也有很大差异：


1.  实例恢复：恢复Oracle数据缓存中丢失的数据

2.  介质恢复：恢复数据库文件丢失的数据


1.1  实例恢复和介质恢复的共同的机制


   实例恢复和介质恢复都依赖重做日志。重做日志由一些重做日志线程组成。单实例环境中重做日志只有一个重做线程，并行服务器环境中每个实例都有一个重做线程。


    一个重做日志线程指的的是一组存放在操作系统上的文件，文件里记录了该实例对数据库的所有变更——已提交的变更和未提交的变更（后者指还存在Oracle数据缓存区中的数据块变更）。因为实例也修改了回滚段中的块，所以回滚段的变更也记录在重做日志线程中。


 
    实例恢复和介质恢复的第一步都是前滚。前滚属于数据库恢复层面的。在前滚的过程中，重做日志中记录的数据变更被重新应用到数据文件中。因为回滚段的变更也记录在重做日志中，所以前滚过程还会重新构建回滚段块。当前滚结束时，重做日志中记录的所有变更都应用到数据文件上了。此刻，数据块不仅包含了已经提交的数据，也包含了一些未提交的数据。


    实例恢复和介质恢复的第二步就是回滚。回滚属于数据库事务层的任务。回滚过程中，回滚段中记录的由前滚导致的未提交的事务所做的修改将被撤销。


1.2  实例失败和恢复，崩溃失败和恢复


  实例失败指当实例突然终止时（如因为shutdown abort或主机掉电），实例数据缓存中的内容就都丢失了。


    崩溃失败指数据库的所有实例都同时失败。单实例环境中实例失败等同于崩溃失败。崩溃恢复指的是将所有实例都恢复到崩溃前的一致状态。这一切都是在命令alter database open 之后自动进行的，用户无法干预。


    实例失败会损害数据库的一致性因为它导致该实例的脏数据丢失。所谓“脏数据”就是指实例数据缓存中的数据块内容比数据文件上的要新。当实例崩溃时，还没有来得及将脏数据写入到数据文件中。之所以导致存在这个脏数据丢失问题是因为Oracle的缓存管理采用的是有利于事务处理性能的算法而不是有利于防止实例崩溃的。如下这些有利于性能调优的缓存管理算法使得实例恢复过程有点复杂：


1.  LRU（最近最少使用）缓存替换算法

2.  提交时不强制将脏数据刷新到数据文件中


 
  上面的算法导致实例失败时对数据库完整性的损害体现在如下几点：


A.  在实例崩溃时，数据文件中可能包含一个原子事务修改的所有块中的部分块而不是全部


B.  在实例崩溃时，数据文件中可能包含一些未提交事务修改的块


C.  在实例崩溃时，一些已提交事务修改的块可能还没有刷新到数据文件中，数据文件中包含的是该事务修改之前的数据块。


    在实例恢复过程中，数据库恢复层修复了上面的损害点A和C，然后后续的数据库事务层修复了损害点B。


除了那些用来修复数据库完整性损害的前提条件外，实例恢复还需要满足一些前提条件：


1. 实例恢复必须在联机的数据文件上进行恢复。

2. 实例恢复必须使用联机重做日志文件，不能要求使用归档重做日志文件。虽然实例恢复也可以通过使用归档重做日志文件进行恢复（数据库运行在非归档模式除外），但那种恢复过程在要求用户先还原归档日志文件的的时候是不能自动进行的。

3. 实例恢复过程的调用是自动的，隐含的在下次数据库启动的时候被调用。

4. 实例恢复过程中侦测修复的文件或修复过程本身都是自动进行的，无需人工干预。

5. 实例恢复中前滚时间的长短是由Oracle数据库内部机制（checkpoint）和用户配置的参数（如日志文件的大小和数量，checkpoint的频率，并行恢复的参数等）决定的。



    综上所述，Oracle的内存管理策略适合于性能调优而不是降低实例崩溃的影响。本文描述了Oracle为解决采用这种LRU和提交不刷新数据块的算法带来的问题所用到的一些内部机制。这些机制保证了实例恢复的前提条件得到满足同时又兼顾了数据库性能。这些机制如下：


1. 提交前先刷新日志块


这个机制修复损害C，保证了在事务提交的时候，所有跟该事务有关的重做日志记录包括提交记录都已经写入到重做日志文件中。


2. 检查点机制


界定了实例恢复时必须应用的重做日志的量。这一点跟联机日志切换结合起来使用确保实例恢复的时候只需要联机重做日志和当前联机数据文件。


3. 联机重做日志切换机制


跟检查点机制结合起来使用确保实例恢复的时候只需要联机重做日志和当前联机数据文件。它保证当前的检查点总是超前即将被重用的联机重做日志文件。


4. 写日志优先


这个机制修复损害A,B，因为a)在实例崩溃时刻，数据文件上的所有变更都在重做日志中找到记录；b)所有数据块在写到数据文件之前都先写入跟回滚段和数据块的重做记录。


5.  写重做日志记录是原子的


这个机制可以修复损害A,B。（注：每笔重做日志记录都是由三个部分组成：重做日志记录头，回滚段改变向量，数据库改变向量。这三部分在写入重做日志时是原子的，不可分割的！）


6.  线程打开标志位

用于数据库启动时判断是否需要崩溃恢复。


1.3  介质失败和恢复

    实例失败影响逻辑上的数据库完整性。因为实例失败的时候数据文件是可以恢复到一致状态的，实例恢复以当前数据文件为起点，用联机重做日志进行恢复。

    介质失败则不同，影响的是物理上的数据库完整性或可用性。因为数据文件已经损坏，介质恢复要先还原该数据文件的备份作为介质恢复的起点，用归档重做日志和联机重做日志做前滚操作，直至数据文件备份后实例崩溃前最近的一个一致状态或者数据文件备份后实例崩溃前的任意一个一致状态。介质恢复操作必须由下面命令来执行：RECOVER DATABASE, RECOVER TABLESPACE, RECOVER DATAFILE。


   根据失败场景分析，介质失败对数据库完整性的破坏可能跟实例失败一样。如当一个块被读入到数据缓冲区中修改后正要被DBWR进程将更新后的数据块写回到数据文件中时发生 I/O故障，也可能导致前面提到的A，B，C三点损害.此外，介质失败时不仅仅是当前脏数据永久丢失了，而且该数据文件上自上次备份后的所有更新的都丢失了。


     在介质恢复之前，必须先还原被损坏的数据文件。然后在这些数据文件上应用相关的归档日志和联机重做日志前滚到介质失败前的一致状态。


      介质恢复和实例恢复上面提到A,B,C三种损害有一些共同的前提条件。然而介质恢复和实例恢复的前提条件还是有如下五点不同：


1. 介质恢复前必须先还原受损坏的数据文件。

2. 介质恢复除了要求联机重做日志外还要有归档重做日志。

3.  介质恢复必须显示调用，需要人工干预。

4.  介质失败不能自动被侦测到。只有在某个数据文件或数据库备份被还原的时候才能自动侦测到需要介质恢复。

5.  介质恢复所用的前滚时间长短是由用户备份策略决定的（如备份的频率，并行恢复参数等），而不是有Oracle内部机制决定。