A-A+

常规恢复思路

2013年08月16日 Backup&Recovery 暂无评论 阅读 1,451 次

这是个常规恢复的小例子,旨在给大家一个恢复的思路,当发生需要恢复的时候,我们不要盲目进行恢复,我们首先要明白恢复哪些文件,为什么恢复,恢复又需要哪些文件,这样一来,我们便可在恢复之前就知道常规恢复能否达到恢复的目的。

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.
标签:

给我留言

Copyright © YallonKing 保留所有权利.   Theme  Ality

用户登录

分享到: