- 最后登录
- 2018-9-14
- 在线时间
- 47 小时
- 威望
- 205
- 金钱
- 2327
- 注册时间
- 2011-10-13
- 阅读权限
- 150
- 帖子
- 90
- 精华
- 0
- 积分
- 205
- UID
- 26
|
1#
发表于 2017-7-28 17:23:33
|
查看: 2280 |
回复: 0
本文目的:
以示例来解释如何在丢失归档日志的情况下,基于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 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号。查询结果如下:- 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开库后,之前的日志备份将不再可用。因此你需要为此数据库做一个新的全备。
|
|