不完全恢复 - Oracle Incomplete Recovery
本文目的：以示例来解释如何在丢失归档日志的情况下，基于Change-Based, Cancel-Based和Time-Based来进行不完全恢复。
--------------------------------------------------------------------------------
执行不完全恢复操作
不完全恢复有时候还是必要的。例如，由于数据库报错，DML误操作导致客户希望数据库回到出事前的状态，而当时归档日志又存在部分丢失。这时候，不完全恢复可能就成为了唯一选项。
不完全恢复可以将数据库恢复到过去的某个时间点。这里有三种方式来执行不完全恢复：基于变更的恢复，基于Cancel的恢复和基于时间的恢复。
考虑在进行数据库恢复时存在以下报错：ORA-308: cannot open archived log 'd:\orant\arc\arch_387.arc
Ora-07360: sfifi: stat error, unable to obtain information...
HP-UX Error: 2: No such file or directoryOracle想要在归档目录中找到序号为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号。查询结果如下：SQL> select first_change#-1, sequence#
2> from v$archived_log
3> where sequence#=387;
FIRST_CHANGE#-1 SEQUENCE#
---------- ----------
9999 387
1 row selected.得到SCN号后，就可以进行不完全恢复了：
1. 以sysdba连接数据库并将数据库mount起来。
2. 执行：
sql> recover automatic database until change 9999;
3. Oracle会在找arch_387.arc之前停止恢复并提示你以下信息：ORA-00289: Suggestion: d:\orant\arc\arch_387.arc
Ora-00280: Change 9999 for thread 1 is in sequence #387
Ora-00278: Logfile 'd:\orant\arc\arch_386.arc' no...
Log applied.
Media recovery complete.
SQL>最后步骤就是去打开数据库了。
--------------------------------------------------------------------------------
Cancel-Based Recovery
基于取消的恢复会不断地去应用redo日志，直到你键入cancel为止。
如在以下提示中键入‘cancel’：Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
或
通过执行'alter database recover cancel' SQL执行语句。让我们再次尝试恢复操作，当你键入命令：SQL> recover database until cancel;
或
SQL> recover database until cancel using backup controlfile (如果控制文件也一并进行恢复)从键入Oracle所需的第一个归档重做日志开始，键入enter继续，不断询问并接受日志，直到Oracle要求序号#387日志，你键入Cancel以结束recover：ORA-00289: Suggestion : d:\orant\arc\arch_386.arc
ORA-00278: Logfile 'd:\orant\arc]arch_386.arc' no...
Specify log: {<RET>=suggest | filename | AUTO | CANCEL}
cancel
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阶段，使用以下命令进行恢复：SQL> recover database until time '2017/07/21:14:42:04';Oracle在提示中建议提供首个归档重做日志。
键入auto，Oracle会自动到归档目录中找所需的归档重做日志直至#387号日志结束。
执行后输出如下：ORA-00280: Change 9999 for thread 1 is in sequence #387
ORA-00278: Logfile 'd:\orant\arcarch_386.arc\ no...
Log applied.
Media recovery complete.注意：当使用基于时间点的恢复时，时间格式为 'YYYY/MM/DD:HH24:MI:SS' 并需在外面括上单引号。
之后的步骤就是打开数据库了。
--------------------------------------------------------------------------------
在完成不完整介质恢复后开库
在Incomplete Recovery之后，数据库必须使用resetlogs项打开：SQL> alter database open resetlogs;注意：reset在线重做日志会进行以下工作：
1. 当这些在线日志当前不存在时，重建它们。
2. 重新在控制文件中对在线重做日志进行初始化，其redo thread会从序号#1开始。
3. 对当前所有数据文件和在线重做日志，使用新的resetlogs SCN和时间戳进行更新。
一旦使用resetlogs开库后，之前的日志备份将不再可用。因此你需要为此数据库做一个新的全备。
页:
[1]