介质恢复用在丢失或损坏数据文件或者丢失了控制文件的情形。介质恢复将还原的数据文件恢复成当前数据文件。还能够恢复数据文件异常脱机时没有来得及做检查点操作丢失的变更。介质恢复使用归档日志和联机日志。跟实例恢复不同的是，介质恢复必须由命令显式调用。

 

 

6.1  什么时候做介质恢复

                由5.3节知道，数据文件如果是还原的备份，在打开前都要进行介质恢复，即使是应用联机日志就可以恢复的。另外一种情形就是数据文件异常脱机没有做检查点操作。不做介质恢复数据库是无法打开的，需要介质恢复的数据文件也不能联机。数据库没有被任何实例打开的时候，介质恢复只能在脱机的数据文件上恢复。即使有崩溃恢复的时候也要在打开数据库显示调用介质恢复命令。此时崩溃恢复可能没有什么做的但还是会自动运行。有时候介质恢复可能发现没有日志要应用，就会报错“不需要介质恢复”，即该文件不需要恢复。

                如果当前控制文件丢失了，将一个备份控制文件还原了，介质恢复就必须做了，这是所有数据文件都联机的时候还要介质恢复的一个例子。

 

 

6.2  线程合并重做程序

                介质恢复应用重做日志时用的是线程合并的重做算法。即它要同时应用所有线程的重做日志，按SCN递增的顺序合并重做日志。在还原的数据文件上应用介质恢复的过程跟在联机数据文件上应用崩溃恢复的过程的不同在于：崩溃恢复同一时刻只会应用来自一个线程的日志，因为同一时刻数据文件上的块只需要最多一个线程的重做日志（同一时刻只有一个实例可能修改该块）。在还原的备份上，则无法猜测跟该块有关的线程数目。通常介质恢复时需要同时读取所有线程的重做日志，然后按照SCN递增的顺序合并重做日志。注意这个算法依赖于数据块的变更各个线程都是按SCN递增的顺序记录的（并行服务器环境中）。

 

 

6.3  还原备份

                在数据库关闭或者数据文件脱机的情况下，可以将该数据文件的备份还原。注意绝不能在数据文件还在使用的情况下还原。每次都数据文件头时都会校验数据文件头部的检查点计数和数据文件在控制文件中的检查点计数以检测是否发生这种非法操作。

 

 

6.4  介质恢复命令

                介质恢复命令有三种：

 

RECOVER DATABASE

 

RECOVER TABLESPACE

 

RECOVER DATAFILE

 

                这三个命令的根本区别在于恢复的数据文件集合不同。三个命令都用同样的标准决定每个数据文件是否要做介质恢复。每个数据文件上都一个排它锁，介质恢复程序开始恢复前会先申请获得这个锁。如果得不到就触发一个错误。这可以防止两个恢复会话同时恢复同一个数据文件以及防止对一个在使用的数据文件进行介质恢复。

               

6.4.1  RECOVER DATABASE

                这个命令用来恢复所有联机数据文件。如果所有实例都正常关闭并且也没有数据文件被还原，这个命令会触发一个“no recovery required”的错误。当有实例已经打开了数据文件时这个命令也会报错因为该实例已经持有所有的锁。

 

 

6.4.2  RECOVER TABLESPACE

                这个命令用来恢复指定表空间上的所有数据文件。为了将表空间名转换成具体的数据文件名，数据库必须先打开。这意味着这个表空间及其所有数据文件在数据库打开前得先脱机才能进行介质恢复。如果该表空间的所有数据文件都不需要介质恢复时会触发一个错误说没有文件需要介质恢复。

 

6.4.3  RECOVER DATAFILE

                这个命令用来恢复指定的数据文件，无论数据库是否打开，只要能获得该数据文件上的介质恢复锁即可。当一个实例已经打开数据库的时候，则只能在脱机的数据文件上做介质恢复。

 

 

6.5  开始介质恢复

                介质恢复时开始查找介质恢复起始SCN。如所有要恢复的数据文件的文件头中最低的检查点SCN。注意：如果一个数据文件的检查点SCN落在它的脱机SCN 范围内（见2.18）则会引发一个异常。此时，该数据文件的脱机结束SCN将替代文件头检查点SCN参与计算介质恢复起始SCN。

                然后每个启用的线程（指在介质恢复开始SCN那一刻处于启用状态的线程，见2.10）都会分配一个缓冲区用来读取重做日志。每个文件的文件头的检查点 SCN被保存下来用来确保在这个SCN以前的重做日志不需要应用。结束SCN（控制文件中记录的）也被保存下来。如果是无穷大则取最大的结束SCN用来告诉介质恢复在何处停止，超出这个SCN的重做日志不需要应用（见6.10）。介质恢复结束时，之前结束SCN为无穷大的数据文件会在该结束SCN处做一个检查点操作（而不是在介质恢复结束点）。这使得一个干净脱机或者只读的数据文件在跟它的表空间干净结束SCN处进行检查点操作。

 

 

6.6  应用重做日志，介质恢复检查点

                每个在介质恢复起始SCN处启用的线程（见2.10）都打开了一个日志。如果该日志是联机状态，就会自动被打开；如果该日志是归档状态，就会提示用户输入日志名称，除非是自动恢复。所有线程中的重做日志按照产生的顺序被应用，在需要的时候还会切换线程。

                有个例外就是在基于取消的不完全恢复（见6.12）或者是备份的控制文件的恢复（见6.13），按序列顺序计算出的下一个联机日志如果在磁盘上会自动被应用，否则会提示输入它的完整路径。

                在日志分界点，介质恢复会执行一个检查点操作。脏数据会被写入到磁盘，数据文件头检查点推进，因此在此之前的重做日志不需要再重新应用。介质恢复的检查点还可能发生在介质恢复结束时会对介质恢复开始时一些结束SCN为无穷大的数据文件在结束SCN处做检查点操作。

 

6.7  介质恢复和模糊状态位

 

6.7.1  介质恢复模糊位

                数据文件头部的介质恢复模糊位用来表示由于在进行介质恢复，该数据文件可能包含比数据文件头部检查点SCN还要晚的数据变更。介质恢复模糊位在介质恢复开始的被设置，通常来说在介质恢复对数据文件头发生一次检查点时该状态位可以被清除。当介质恢复成功结束或失败时该状态位才算永久清除。在8.1将见到，在不完全恢复后以重置日志方式打开数据库，如果还有数据文件的介质恢复模糊位被设置，将会打开失败。

 

6.7.2  联机模糊位

                介质恢复在碰到一个崩溃恢复结束标记（或者一个立即脱机的标记：发生在数据文件还没有做检查点操作就脱机），介质恢复会在下一个介质恢复检查点清除数据文件头的联机模糊位和热备模糊位（如果被设置）。

 

6.7.3  热备份模糊位

                在碰到一个结束热备份标记（或者一个崩溃恢复结束标记），介质恢复会在下一个介质恢复检查点操作时清除热备份模糊位。在不完全恢复后以重置日志方式打开数据库时如果有数据文件热备份模糊位或其他模糊位被设置，打开将失败。这防止了不完全恢复在热备份开始和结束中间时间点结束时还能以重做日志方式成功打开数据库。在这样的时间点结束不完全恢复将会导致数据文件处于不一致状态，因为还原的备份可能包含该结束点和热备份结束点之间的数据库变更。

 

6.8  线程启用

            当一个实例启用一个新线程的时候会在该线程的重做日志中写入一笔线程启用记录。当介质恢复碰到这样的记录时就重新分配一个重做日志缓冲区，打开新的线程的重做日志，开始应用它的重做日志。

 

 

6.9  线程禁用

            线程被禁用的时候，它的当前日志被标记为线程结束。介质恢复应用完该重做日志后，会释放它的重做日志缓冲区并停止查找该线程的重做日志。

 

 

6.10  结束介质恢复（完整的介质恢复）

            每个线程的当前日志（也是最后一个）都会有个线程结束标记。完整的介质恢复（相对于不完全恢复，见6.12）都会应用重做日志直至所有线程的线程结束处。线程结束标记可以认为是没有当前控制文件，因为线程结束标记在日志头部而不是在控制文件中的记录中。

            注意：备份当前联机日志并在后面还原是很危险的，很容易导致对当前线程结束的误判。因为备份中的线程结束标记相对于当前线程结束的日志而言是过期了的。

            如果正在做介质恢复的数据文件在控制文件中（假定是当前控制文件）的结束SCN是无穷大，介质恢复将会联机程结束之前停止，重做程序将联机程结束点的SCN处停止，因为没有超出这个SCN的重做日志存在了。

            像2.15中描述的那样，结束SCN是在数据文件脱机时被设置的。如果没有上面这个处理方式，将不能保证数据库打开的时候在结束SCN无穷大的数据文件上的介质恢复何时能停止。

 

 

6.11  自动恢复

            当介质恢复命令后加上AUTOMATIC选项时将会自动进行介质恢复。它省去了让用户输入归档重做日志文件路径的麻烦，前提是它们在磁盘上。只要日志序号能确定，日志文件名就可以根据数据库初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_FORMAT计算出来。除非用户指定其他的归档目录，当前LOG_ARCHIVE_DEST指定的值将会被使用。介质恢复开始检查点（见6.5）中包含（RBA字段中）线程（产生该开始检查点的线程）初始的日志序号。如果启用了多个重做日志线程，将根据控制文件中的日志历史记录部分将开始SCN映射到各个线程对应的日志序列号。一旦第一个恢复用的日志找到了，后续的日志按顺序应用。如果不能确定初始的日志序号，用户就得猜测直到找到正确的日志。介质恢复开始检查点中的timestamp字段值将帮助用户决定。

 

 

6.12  不完全恢复

            RECOVER DATABASE命令可以在所有重做日志被应用前停止，这种类型的恢复就是不完全恢复。不完全恢复后打开数据库必须以重置日志方式打开。

            不完全恢复将数据库恢复到指定时间点或之前的数据库一致状态。所有后续的更新将丢失。

            不完全恢复主要用于下列情形：

a.       因为有文件损坏必须进行介质恢复，但由于某个归档日志或联机日志损坏或丢失，不能进行完全恢复。

b.       所有处于启用状态的联机日志都不可用，因此无法进行实例恢复，这个情形变成上一个情形。

c.       为了恢复一个用户错误的操作（如删了表或者数据等），将数据库恢复到错误操作之前的一个数据库一致的点

 

6.12.1  Incomplete Recovery UNTIL Options

            根据停止的方式分，不完全恢复有三种类型：

a.       基于取消的不完全恢复，命令：RECOVER DATABASE UNTIL CANCEL

b.       基于SCN的不完全恢复，命令：RECOVER DATABASE UNTIL CHANGE

c.       基于时间点的不完全恢复，命令：RECOVER DATABASE UNTIL TIME

 

基于取消的不完全恢复在用户输入cancel（而不是日志路径）的时候停止恢复。联机日志也不会自动被应用，防止在下一个日志开始前取消。如果多个线程要进行恢复，可能照成某些线程的重做日志只是部分应用。

基于SCN的不完全恢复停止应用指定SCN以及更高SCN相关的重做日志。因此在该SCN时提交的事务（或更晚提交）将会被回滚。如果你想恢复到某个事务提交点SCN时，将将该SCN值加一。

基于时间点的不完全恢复，跟基于SCN的不完全恢复类似，只是输入的是时间点。介质恢复根据重做日志块头部的时间来将该时间点转换成SCN，然后恢复到该SCN处停止。

 

6.12.2  不完全恢复和数据一致性

为了防止不完全恢复破坏数据库完整性，所有数据文件必须恢复到同一点。并且没有任何一个数据文件拥有该点之后的数据库变更。这就要求介质恢复用的数据文件必须是从早于期望恢复的时间点之前的备份中还原出来的。系统用文件头的模糊位（见8.1）来保证数据文件上没有停止时间点之后的变更。

 

6.12.3  不完全恢复和控制文件记录的数据文件

如果要不完全恢复到某个数据文件被删除的时间点之前，则控制文件中必须有该被删除的数据文件记录，否则无法进行恢复。而现有的控制文件已经没有该数据文件的记录了。一个可选的方法就是恢复的时候使用删除数据文件之前时间点备份的控制文件进行不完全恢复；另一个可选的方法就是用CREATE CONTROLFILE命令创建一个控制文件包含被删除的数据文件。

不完全恢复到某个数据文件被添加之前的时间点倒没有什么问题。新增的数据文件会在恢复后打开数据库时被忽略，为了避免介质恢复访问该数据文件，该数据文件可能被脱机。

 

6.12.4  不完全恢复后以重置日志方式打开数据库

不完全恢复后下一步就是以RESETLOGS选项打开数据库。其中一个影响（见第7节）就是数据库丢弃了不完全恢复中没用用到的重做日志，并且后续恢复将再也无法应用这些重做日志。如果是错误的进行了不完全恢复（比如说又找到了丢失的日志），下一步可以以NORESETLOGS选项打开数据库。如果打开成功了，则需要进行成功的完全恢复。

 

6.12.5  不完全恢复中的脱机文件

如果不完全恢复中某个数据文件处于脱机状态，它不会被恢复。如果该文件是正常脱机的表空间的一部分，不被恢复就没问题。它将一直处于脱机状态直至恢复结束。否则，如果以重置日志方式打开数据库后该数据文件仍然是脱机状态，该数据文件所在表空间将不得不被删除。因为它需要重置日志之前的日志进行介质恢复。通常在介质恢复之前都要去检查 V$DATAFILE中保证数据文件都联机。只有那些是正常脱机的表空间的数据文件且该数据文件将会被删除的才能在不完全恢复中保持脱机（见8.6）。

 

6.13  基于备份的控制文件的恢复

如果介质恢复时控制文件比当前控制文件旧，则需要进行基于备份的控制文件的恢复（RECOVER DATABASE...USING BACKUP CONTROLFILE）。这适用于控制文件是从一个备份中还原出来的或者用CREATE CONTROLFILE...RESETLOGS命令创建的备份控制文件。

CREATE CONTROLFILE...RESETLOGS命令似的控制文件是一个“备份”。在这个命令之后只能进行基于备份控制文件的恢复，只能用RESETLOGS选项打开数据库。这个命令意味着所有的联机重做日志和控制文件备份都丢失。

相比之下，命令CREATE CONTROLFILE...NORESETLOGS使得控制文件最新。如记录了最新的联机日志和日志序号。这个命令后介质恢复不是必需的。事实上，如果是以“干净”的方式关闭并且没有数据文件是从备份中还原出来的，则不需要进行任何恢复。此后可以以正常的方式或者NORESETLOGS方式打开数据库。

一个备份的控制文件缺乏当前联机日志和数据文件结束SCN的正确信息。因此恢复进程不能找到联机日志并自动应用。并且，恢复进程还得假定结束SCN是无穷大。以RESETLOGS选项打开数据库会纠正该信息。备份的控制文件中包含的启用的线程集合可能跟原始的控制文件也不同，以RESETLOGS选项打开数据库后也会纠正该线程集合信息。

BACKUP CONTROLFILE选项可以独立使用，也可以结合不完全恢复。除非使用了不完全恢复选项，所有线程都要应用重做日志直至线程结束为止。这个会在以RESETLOGS选项打开数据库时验证。

当还原了一个备份的控制文件后，即使没有执行不完全恢复，也会要求以RESETLOGS选项打开数据库。当问题仅仅是因为丢失了当前控制文件（并且存在控制文件备份），下面步骤用来避免基于控制文件的恢复和重置日志：

1. 将备份控制文件复制到当前控制文件位置，然后将数据库启动到MOUNTED状态。
2. 执行ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS.
3. 执行第二步中得到跟踪文件中的SQL：CREATE CONTROLFILE...NORESETLOGS

第三步中的CREATE CONTROLFILE...NORESETLOGS命令很重要，它反映了数据库的结构信息，跟丢失的控制文件一样。如在控制文件备份后添加了一个数据文件，那么CREATE CONTROLFILE 命令就要包含该数据文件的信息。

当控制文件确实是备份的控制文件时，在RECOVER DATABASE命令时用BACKUP CONTROLFILE选项将会失败，这个很快就能检测到。一个迹象就是数据文件头的检查点计数比该数据文件在控制文件中的记录的检查点计数要大。这个测试可能也不能测不出备份控制文件，因为可能数据文件也是从备份中还原。另外一个测试是验证联机日志文件头部跟它们在控制文件中的记录，同样也可能无法测出一个备份控制文件。

 

 

6.14  创建数据文件：恢复一个备份中没有的数据文件

如果数据文件丢失或损坏了，而且还没有任何备份，它可以通过重做日志和控制文件中的记录恢复，前提是满足一下条件：

1. 自该数据文件创建后的所有重做日志文件都可用。
2. 包含该数据文件的信息（名称和大小等）的控制文件可用或者可以重建。

 

首先用ALTER DATABASE CREATE DATAFILE 创建一个新的空的数据文件以替换丢失的数据文件，然后在该数据文件上通过命令RECOVER DATAFILE 应用重做日志，从数据文件创建的时间起到丢失或损坏的那一刻为止。当期间的所有重做日志都应用后，该数据文件就跟丢失前的那一刻状态一致了。这个方法对恢复最近创建的数据文件且没有相应备份的情形很有用。不过SYSTEM表空间的原始数据文件不能用这个方法恢复，因为在数据库创建的时候还没有相应的重做日志保存下来。

 

6.15  用Export/Import进行即时恢复

偶尔，我们要撤销某个错误的操作（如删除表或者大量数据等）。一个途径就是执行一个在错误时间点之前的不完全恢复，然后重置日志打开数据库。这种方法就导致整个数据库——不仅仅是出错的几个SCHEMA对象——要回到一个过去的时间点。

这个方法有个副作用，就是它丢弃了提交的事务。任何发生在重置日志SCN后的更新都丢失了。重做日志的另外一个副作用就是使得之前所有的备份对将来的恢复都没有用。

因此将数据库全部回滚到过去的一个时间点并不是一个可以接受的方案。下面这个替代方案的副作用仅仅是将受影响的范围限制到恢复的几个对象。

即时不完全恢复是发生在产品数据库的副本上——称之为用于恢复的数据库。该数据库的初始状态取的是产品库发生在那个错误操作之前的备份，在副本数据库上可以将不相干的数据库对象都脱机以避免不必要的恢复。不过SYSTEM表空间和回滚段所在的表空间必须参与恢复以保证能以‘干净的’方式打开数据库。（这也说明了回滚段和数据文件应该分开存放）。

当介质恢复到错误时间之前的那一刻后，以重置日志方式打开数据库。此时数据库处于错误操作之前的一个时间点，等于有了个出错前的数据库版本。将错误操作影响的数据库对象用EXPORT导出来然后导入到产品库中。在导入到产品库之前，先做以下准备：

1. 为了恢复一个错误的更新操作，在产品库把受影响的表里的数据先清除掉。如truncate表数据。
2. 为了恢复一个错误的删除操作，在产品库里先重建一下被删除的对象（保持空数据）。

 

然后最重要的一步就是用IMPORT导入，选择只导入数据。因为EXPORT/IMPORT是一个漫长的过程，因此可以推迟到无法忍受的时间点执行。同时要恢复的对象也可以通过在产品库和副本库间建DBLINK来随时同步。

这种即时恢复的一个副作用就是跟要恢复的对象有关的事务一致性可能无法保证，不过这个副作用可以通过把要恢复的对象面扩展到跟该事务有关的所有数据库对象。

 

继第七章 Oracle恢复内部原理（块修复）

**********本博客所有内容均为原创，如有转载请注明作者和出处!!!**********
Name:    guoyJoe

QQ:        252803295

Email:    oracledba_cn@hotmail.com

Blog:      http://blog.csdn.net/guoyJoe

ITPUB:   http://www.itpub.net/space-uid-28460966.html

OCM:    
_____________________________________________________________
加群验证问题：哪些SGA结构是必需的，哪些是可选的？否则拒绝申请!!!

答案在：http://blog.csdn.net/guoyjoe/article/details/8624392

Oracle@Paradise 　总群:127149411

Oracle@Paradise No.1群:177089463(已满)

Oracle@Paradise No.2群:121341761

Oracle@Paradise No.3群:140856036