不完全恢复 - Oracle Incomplete Recovery

biotwang

本文目的：

以示例来解释如何在丢失归档日志的情况下，基于Change-Based, Cancel-Based和Time-Based来进行不完全恢复。

--------------------------------------------------------------------------------
执行不完全恢复操作

不完全恢复有时候还是必要的。例如，由于数据库报错，DML误操作导致客户希望数据库回到出事前的状态，而当时归档日志又存在部分丢失。这时候，不完全恢复可能就成为了唯一选项。
不完全恢复可以将数据库恢复到过去的某个时间点。这里有三种方式来执行不完全恢复：基于变更的恢复，基于Cancel的恢复和基于时间的恢复。

考虑在进行数据库恢复时存在以下报错：

1. ORA-308:  cannot open archived log 'd:\orant\arc\arch_387.arc
   
2. Ora-07360: sfifi: stat error, unable to obtain information...
   
3. HP-UX Error: 2: No such file or directory

复制代码

Oracle想要在归档目录中找到序号为387的归档重做日志。但是你发现arch_387不可用：
arch_382.arc        arch_386.arc
arch_383.arc        arch_388.arc
arch_384.arc        arch-389.arc
arch_385.arc        arch-390.arc

因此仅有可用的方法就是数据库不完全恢复。
你需要先从之前的备份中restore数据库。然后使用以下任意一种方式进行recover操作：

--------------------------------------------------------------------------------
Change-Based Recovery

为了进行基于变更的恢复，你需要知道（在丢失的那个日志之前的)归档重做日志中的最大的system change number(SCN)。这样你就可以使用恢复命令将数据库recover到那个指定的scn_number上。这个scn_number存在于需要为386的归档重做日志中（比387号日志小1号，最近的那个文件）。你可以通过查询v$archived_log视图来获得SCN信息。

注意：v$archived_log视图中存储了每个归档重做日志的中的首个SCN，因此你需要从下一个sequence# 日志文件的first_change#减1来得到日志文件中的最大SCN号。因为我们要找的是386号文件的最后一个SCN号，所以这个SCN号的值就需要以#387作为日志文件记录查找参考。

通过 select first_change#-1, sequence# from v$archived_log where sequence#=387; 我们可以找到所需的SCN号。查询结果如下：

1. SQL> select first_change#-1, sequence#
   
2.      2> from v$archived_log
   
3.      3> where sequence#=387;
   
4. 
   
5. FIRST_CHANGE#-1  SEQUENCE#
   
6. ----------       ----------
   
7.       9999             387
   
8. 1 row selected.

复制代码

得到SCN号后，就可以进行不完全恢复了：
1. 以sysdba连接数据库并将数据库mount起来。
2. 执行：
sql> recover automatic database until change 9999;
3. Oracle会在找arch_387.arc之前停止恢复并提示你以下信息：

1. ORA-00289:  Suggestion: d:\orant\arc\arch_387.arc
   
2. Ora-00280:  Change 9999 for thread 1 is in sequence #387
   
3. Ora-00278:  Logfile 'd:\orant\arc\arch_386.arc' no...
   
4. Log applied.
   
5. Media recovery complete.
   
6. SQL>

复制代码

最后步骤就是去打开数据库了。

--------------------------------------------------------------------------------
Cancel-Based Recovery

基于取消的恢复会不断地去应用redo日志，直到你键入cancel为止。
如在以下提示中键入‘cancel’：

1. Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
   
2. 或
   
3. 通过执行'alter database recover cancel' SQL执行语句。

复制代码

让我们再次尝试恢复操作，当你键入命令：

1. SQL> recover database until cancel;
   
2. 或
   
3. SQL> recover database until cancel using backup controlfile (如果控制文件也一并进行恢复)

复制代码

从键入Oracle所需的第一个归档重做日志开始，键入enter继续，不断询问并接受日志，直到Oracle要求序号#387日志，你键入Cancel以结束recover：

1. ORA-00289:  Suggestion : d:\orant\arc\arch_386.arc
   
2. ORA-00278:  Logfile 'd:\orant\arc]arch_386.arc' no...
   
3. Specify log: {<RET>=suggest | filename | AUTO | CANCEL}
   
4. cancel
   
5. Media recovery cancelled.

复制代码

之后打开数据库。

--------------------------------------------------------------------------------
Time-Based Recovery

为了应用基于时间点恢复，你需要知道#387归档重做日志在v$archived_log中对应记录的时间。执行以下语句：
SQL>  select first_time from v$archived_log where sequence# = 387;
FIRST_TIME
------------------
07/21/17 14:42:04

数据库处于mount阶段，使用以下命令进行恢复：

1. SQL> recover database until time '2017/07/21:14:42:04';

复制代码

Oracle在提示中建议提供首个归档重做日志。
键入auto，Oracle会自动到归档目录中找所需的归档重做日志直至#387号日志结束。

执行后输出如下：

1. ORA-00280: Change 9999 for thread 1 is in sequence #387
   
2. ORA-00278: Logfile 'd:\orant\arcarch_386.arc\ no...
   
3. Log applied.
   
4. Media recovery complete.

复制代码

注意：当使用基于时间点的恢复时，时间格式为 'YYYY/MM/DD:HH24:MI:SS' 并需在外面括上单引号。

之后的步骤就是打开数据库了。

--------------------------------------------------------------------------------
在完成不完整介质恢复后开库

在Incomplete Recovery之后，数据库必须使用resetlogs项打开：

1. SQL>  alter database open resetlogs;

复制代码

注意：reset在线重做日志会进行以下工作：
1. 当这些在线日志当前不存在时，重建它们。
2. 重新在控制文件中对在线重做日志进行初始化，其redo thread会从序号#1开始。
3. 对当前所有数据文件和在线重做日志，使用新的resetlogs SCN和时间戳进行更新。

一旦使用resetlogs开库后，之前的日志备份将不再可用。因此你需要为此数据库做一个新的全备。