A-A+
常规恢复思路
这是个常规恢复的小例子，旨在给大家一个恢复的思路，当发生需要恢复的时候，我们不要盲目进行恢复，我们首先要明白恢复哪些文件，为什么恢复，恢复又需要哪些文件，这样一来，我们便可在恢复之前就知道常规恢复能否达到恢复的目的。
SQL> startup ORACLE instance started. Total System Global Area 939495424 bytes Fixed Size 2233960 bytes Variable Size 545261976 bytes Database Buffers 385875968 bytes Redo Buffers 6123520 bytes Database mounted. ORA-01113: file 5 needs media recovery ORA-01110: data file 5: '/u01/app/oracle/oradata/ora11gr2/yallonking01.dbf'
当我们正常启动数据库的时候，发现5号文件需要介质恢复。
下边我们分析下，为什么5号文件需要恢复
我们首先要确定的是，文件的新旧问题。我们可以通过以下方式获知指定文件的scn，来确定文件的新旧。
首先我们可以通过相关视图，查看控制文件中的scn点，以及需要恢复文件的scn点
SQL> col name for a50
SQL> set line 400
SQL> select FILE#,NAME,CHECKPOINT_CHANGE#,CHECKPOINT_TIME from v$datafile;
FILE# NAME CHECKPOINT_CHANGE# CHECKPOIN
---------- -------------------------------------------------- ------------------ ---------
1 /u01/app/oracle/oradata/ora11gr2/system01.dbf 787354 16-AUG-13
2 /u01/app/oracle/oradata/ora11gr2/sysaux01.dbf 787354 16-AUG-13
3 /u01/app/oracle/oradata/ora11gr2/undotbs01.dbf 787354 16-AUG-13
4 /u01/app/oracle/oradata/ora11gr2/users01.dbf 787354 16-AUG-13
5 /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf 787354 16-AUG-13
SQL> select FILE#,CHANGE# from v$recover_file;
FILE# CHANGE#
---------- ----------
5 787139
众所周知，在数据库检查一致性的时候，先检查控制文件序列号（注意区别于日志文件的序列号），然后再校验SCN，如果控制文件序列号都没有校验通过，则直接报恢复，否则再进行scn的校验。
控制文件序列号在数据文件、日志文件、控制文件的头部存在，日志文件和数据文件头中存在的控制文件序列号均是从控制文件中复制过来的，而每当日志文件或者数据文件发生变化，他们的头部控制文件序列号便会从控制文件件进行复制，加之像增量检查点信息这些操作只会修改控制文件的头部，所以，控制文件中记录的控制文件序列号一般都比数据文件及日志文件中记录的控制文件序列号大。
SQL> select CONTROLFILE_SEQUENCE# from v$database; //此处查询控制文件中记录的控制文件序列号，该号应该大于下边查出的数据文件中记录的控制文件序列号，以标示控制文件最新。
CONTROLFILE_SEQUENCE#
---------------------
978
SQL> select hxfil,fhcsq from x$kcvfh; //此处查看每个数据文件头中的控制文件序列号
HXFIL FHCSQ
---------- ----------
1 971
2 971
3 971
4 971
5 932 //此处发现，该文件中记录的控制文件序列号滞后于其他文件中记录的控制文件序列号，故需要恢复
下边我们通过BBED来查看问题文件和其他文件的头中记录的日志文件序列号，这样，我们就可以找到恢复需要从哪个序列到哪个序列的日志文件（归档日志）了。
首先看5号问题文件头中记录的日志序列号
BBED> dump dba 5,1 offset 500 count 4
File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5)
Block: 1 Offsets: 500 to 503 Dba:0x01400001
------------------------------------------------------------------------
56000000
<32 bytes per line>
SQL> select to_number('00000056','xxxxxxxx') from dual; //注意字节序
TO_NUMBER('00000056','XXXXXXXX')
--------------------------------
86 //此处滞后于下边查出的1号文件中记录的日志序列号，故恢复该文件，需要从该序列开始
查看1号文件的seq
BBED> dump dba 1,1 offset 500 count 4
File: /u01/app/oracle/oradata/ora11gr2/system01.dbf (1)
Block: 1 Offsets: 500 to 503 Dba:0x00400001
------------------------------------------------------------------------
5d000000
<32 bytes per line>
SQL> select to_number('0000005d','xxxxxxxx') from dual;
TO_NUMBER('0000005D','XXXXXXXX')
--------------------------------
93
下边进一步查看这2个文件的scn
首先看问题5号文件的scn
BBED> dump dba 5,1 offset 484 count 4
File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5)
Block: 1 Offsets: 484 to 487 Dba:0x01400001
------------------------------------------------------------------------
c3020c00
<32 bytes per line>
SQL> select to_number('000c02c3','xxxxxxxx') from dual;
TO_NUMBER('000C02C3','XXXXXXXX')
--------------------------------
787139 //此处和我们前边从视图 v$recover_file 查出来的一致
继续查看1号文件的scn
BBED> dump dba 1,1 offset 484 count 4
File: /u01/app/oracle/oradata/ora11gr2/system01.dbf (1)
Block: 1 Offsets: 484 to 487 Dba:0x00400001
------------------------------------------------------------------------
9a030c00
<32 bytes per line>
SQL> select to_number('000c039a','xxxxxxxx') from dual;
TO_NUMBER('000C039A','XXXXXXXX')
--------------------------------
787354 //此处和我们之前从视图 v$datafile 查出来的一致
此时，我们可以很清楚的知道，要使5号数据文件恢复，就需要scn在 787139 到 787354 之间的所有的日志记录（redo+archivelog）。
或者是需要从日志序列 86 开始到 93 的日志中的记录。
当然，我们也可以直接使用BBED将5号文件的scn修改成控制文件中记录的值,以及将seq修改成当前的seq跳过日志恢复使该文件非常规的得到恢复。
此处我们使用常规方式寻找恢复所需的日志文件。
由于是非系统文件，所以我们可以先把该数据文件离线，将数据库打开对外提供服务。
SQL> alter database datafile 5 offline; Database altered. SQL> alter database open; Database altered.
此处我们查看我们所需的归档日志文件有哪些
SQL> select NAME,SEQUENCE#,FIRST_CHANGE# from v$archived_log 2 where FIRST_CHANGE#>=( 3 select max(FIRST_CHANGE#) from v$archived_log 4 where FIRST_CHANGE#<787139); NAME SEQUENCE# FIRST_CHANGE# ------------------------------------------------------------------------------------------ ---------- ------------- /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_86_90w29sxn_.arc 86 782843 /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_87_90w29v1h_.arc 87 787167 /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_88_90w29y1c_.arc 88 787170 /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_89_90w2b9vj_.arc 89 787173 /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_90_90w2bcm3_.arc 90 787180 /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_91_90w2bd9h_.arc 91 787184 /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_92_90w2bdyh_.arc 92 787188 7 rows selected.
当然，我们也需要redo日志文件的
SQL> select a.MEMBER,b.SEQUENCE#,b.STATUS,b.ARCHIVED from v$logfile a,v$log b where a.GROUP#=b.GROUP#; MEMBER SEQUENCE# STATUS ARC -------------------------------------------------- ---------- ---------------- --- /u01/app/oracle/oradata/ora11gr2/redo01.log 91 INACTIVE YES /u01/app/oracle/oradata/ora11gr2/redo02.log 92 INACTIVE YES /u01/app/oracle/oradata/ora11gr2/redo03.log 93 CURRENT NO
下边，我们使用常规手段恢复该数据文件
SQL> recover datafile 5;
ORA-00279: change 787139 generated at 08/16/2013 19:12:12 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_86_90w29sxn_.arc
ORA-00280: change 787139 for thread 1 is in sequence #86 //此处的第一个日志序列号和我们之前讨论的一致
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto //此处选择自动
ORA-00279: change 787167 generated at 08/16/2013 19:12:57 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_87_90w29v1h_.arc
ORA-00280: change 787167 for thread 1 is in sequence #87
ORA-00279: change 787170 generated at 08/16/2013 19:12:58 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_88_90w29y1c_.arc
ORA-00280: change 787170 for thread 1 is in sequence #88
ORA-00279: change 787173 generated at 08/16/2013 19:13:01 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_89_90w2b9vj_.arc
ORA-00280: change 787173 for thread 1 is in sequence #89
ORA-00279: change 787180 generated at 08/16/2013 19:13:13 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_08_16/o1_mf_1_90_90w2bcm3_.arc
ORA-00280: change 787180 for thread 1 is in sequence #90
Log applied.
Media recovery complete.
恢复完成，我们将数据文件在线即可。
SQL> alter database datafile 5 online; Database altered.
