[原]Oracle恢复流程

女朋友五一不在，少了很多乐趣，本打算去几个地方走走玩玩，看来计划不得实现。于是集中时间，整理了以下内容。全面介绍Oracle恢复的常用15步（未包括全部），以飨读者！如有笔误，敬请指出。

step1 所有的datafile和redo log file都正确吗？
Create controlfile脚本只有在所有数据文件及在线日志都无误时才起作用。redo必须

是当前的而且是完整无缺的。
原因：重建过程在重建控制文件的时候查看每个数据文件。每个datafile包含一个scn，

scn与一个特定的在线重做日志对应。如果数据文件指示其scn比可用的在线重做日志新

的话，则控制文件重建过程会中止！

step2 恢复被破坏的datafile及redo log file
判断是否有其他被破坏的datafile
1 找出所有的datafile和redo log file的位置
startup mount
select name from v$controlfile;
select group#,member from v$logfile;
2 检查数据文件：
是否丢失文件或者文件长度为0
是否存在有一个或者多个文件修改时间比最新在线redolog文件更新的情况，如果是的话

，则必须从备份中恢复这个数据文件。
3 检查redolog：
同组日志成员有着相同的修改时间及大小
3.1 如果一个或者多个日志组中包含至少一个正确及一个不正确的日志，
那么，利用镜像，将正确的log copy到破坏的位置。
3.2 如果至少一个日志组的所有log被破坏了，
这种情况是很糟糕的。因为create controlfile需要具备所有的在线重做日志。如果一

个日志组被破坏，那么将不能重建控制文件，需要alter database open resetlogs;
注意：其实即使所有的redo log都丢失了，也可以create controlfile，但是这个时候

使用的是resetlogs选项，数据丢失是必然的。这个地方不要有误解，之所以说create

controlfile需要具备所有的在线重做日志是为了尽可能减少数据丢失。

step3 运行create controlfile脚本
找到包含create controlfile脚本的跟踪文件（在udump下，使用alter database

backup controlfile to trace;创建）
复制更名为rebldctlfile.sql，编辑其内容，在数据库 nomount的状态下执行脚本。
注意：如果该实例的任一数据文件丢失，则转到step1,step2。
如果该实例的任一重做日志被破坏或者已丢失，则转到step4。

step4 重新装载controlfile，并且为数据恢复做准备
4.1 从备份恢复控制文件，该备份的控制文件必须比实例中最新的数据文件新！
4.2 startup mount;
4.3 使只读表空间离线，因为在执行recover database using backup controlfile时，

不允许只读数据文件在线。
select enabled,name from v$datafile;
alter database datafile 'filename' offline;
4.4 如果完成，进入step5。

step5 恢复数据库
1 试着正常恢复数据库 recover database;
如果可行，则转到step6。否则继续，可能的错误信息如下：
ora-01207:file is more recent than controlfile-old
2 通过备份的控制文件恢复数据库
recover database using backup controlfile;
如果抱错，可能是因为有一些数据文件丢失或者损坏，如果是的话，则转到step1,step2

。
注意：有时候，恢复数据库会进入进退维谷的泥潭，并且Oracle总是抱怨数据文件比控

制文件版本更新！避免这一问题的唯一的方法是：采用一个比控制文件备份版本更老的

数据文件备份。介质恢复将前滚丢失文件的任何改变。
3 应用所有的归档重做日志
Oracle会请求最旧的恢复数据文件时间之后的所有归档重做日志。
4 如果在线重做日志可用，则应用之
可行的话，Oracle会自动前滚所有的归档日志以及在线日志，然后输出media recovery

complete。然而一旦前滚了所有的归档重做日志，它可能会提示需要在线重做日志，其

序号要比最新的归档日志高。试着用所有的在线重做日志来回答这里的提示，一旦输入

的文件不是DB需要的，就不得不重新来过，recover database using backup

controlfile。
如果试过所有的在线重做日志，它仍旧提示输入日志文件，只需输入“cancel”即可。
5 alter database open resetlogs;
一旦介质恢复完成，必须使用这个命令打开数据库。
6 重要的最后一部：执行备份

step6 alter database open;
按照前面步骤，到这里的话，就是alter database open;

step7 恢复系统表空间的所有数据文件
从最近的可用备份中恢复已破坏的文件，在mount状态下执行recover tablespace

system;

step8 破坏了非系统文件数据文件
这个应该简单，先从有效备份中恢复这个破坏的数据文件，然后mount状态下执行

recover datafile ...

step9 使数据文件重新在线
从最新的有效备份中重新装载数据文件
数据文件恢复：recover datafile ...;
alter database datafile 'filename' online;
表空间恢复：alter tablespace ... offline;
recover tablespace ....;
alter tablespace online;
数据库恢复：recover database;
alter database open;

step10 日志被破坏修复--当前日志被破坏
如果当前在线日志被破坏，当试着打开数据库时，会出现下列消息：ora-00313、ora-

00312。这是最糟糕的一种失败，因为这样一定会有数据丢失！因为当前在线日志需要重

新开始。当前控制文件知道当前在线日志，并尝试使用它。
关于这种情况的解决方法是重新装载一个老版本的控制文件。不幸的是，你不能只装载

控制文件，因为这样的话，数据文件会比控制文件新。剩下的选择就是重新装载整个数

据库。转setp11

step11 当前日志被破坏，从备份中恢复所有数据库文件
警告：这个步骤可以说是数据库恢复方法中对糟糕的了，如果不是万不得已，就不要使

用。仅当确定控制文件及当前在线日志组的成员均被破坏时，才执行这一步。这一步相

对容易，确定所有数据文件的名字和位置，并且从他们的最新备份中重新装载就可以了

。
注意：首先尝试只重新装载datafile，不装载controlfile进行恢复。一旦所有数据文件

均已重新装载，进入step12。

setp12 alter database open resetlogs
警告：不到万不得已不要使用！
这个command让Oracle在清除所有在线重做日志的内容后打开数据库。由于没有办法撤销

这一步，所以需要为重做日志文件做备份。
select * from v$logfile;
为在线重做日志做完备份后，执行：
alter database open resetlogs;
如果数据库打开，最好进行一次全冷备。

step13 如果active状态的在线重做日志被破坏
报错：ora-00313 ora00312，日志组处于avtive状态。
请切记，active的日志组在恢复时仍然需要用到，因为检查点尚没有将所有的改变从共

享内存刷新至硬盘。一旦刷新完毕，就不再需要这个日志了。

step14 执行检查点
alter system checkpoint local;
保持耐心，等待Oracle显示该检查点成功或者失败。成功会显示“statement processed
”
注意：执行检查点之后，即使没有成功，也要试着打开数据库。如果尝试打开失败，回

到step11，恢复整个DB。

step15 如果incative状态的在线重做日志被破坏了
小事一桩，inactive日志不是Oracle必须的，如果不需要，只要丢弃它并在其位置上添

加另一个日志即可。
假设被破坏的是inactive的日志组2
startup mount
select member from v$logfile where group#='2';
alter database drop logfile group 2;
alter database add logfile group 2
('....redo01.dbf','....redo02.dbf','...redo03.dbf') size 200m;

然后尝试打开数据库。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/593324/viewspace-376194/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/593324/viewspace-376194/