ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Recover physical standby database after loss of archive log(2)

Recover physical standby database after loss of archive log(2)

原创 Linux操作系统 作者:aaqwsh 时间:2012-06-23 21:07:50 0 删除 编辑

前几天一起和同事处理过一起归档丢失的dg,记录一下:上次写过一篇DG丢失归档后的处理过程,总体来说就是使用增量备份覆盖gap数据从而跳过gaparchivelog 这里再阐述另一种情况

[oracle@db61 orcl]$
SQL*Plus: Release 10.2.0.5.0 - Production on Wed Jun 20 14:35:01 2012

Copyright (c) 1982, 2010, OracleAll Rights Reserved.
 
SQL> select database_role from v$database
;
DATABASE_ROLE

--------------
--
PHYSICAL STANDBY

SQL> recover standby database;
ORA-00279: change 40103914365 generated at 05/23/2012 09:26:36 needed for thread 3

ORA-00289: suggestion : /data/oracle/oradata/orcl/arch/3_8658_657561562.dbf

ORA-00280: change 40103914365 for thread 3 is in sequence #8658

 
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto
ORA-00308: cannot open archived log '/data/oracle/oradata/orcl/arch/3_8658_657561562.dbf'

ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3

这个库的大概情况为丢失了64号至今的所有归档,很容易想到使用standby current_scn去作为 起始scn增量备份,对于这里的增量备份出现了一个有趣的现象。看上面的操作,可以知道还是需要scn40103914365的归档文件,but why ?既然已经使用增量备份recover database,这里就不兜圈子了,DG开启redo apply之后 oracle 会寻找file header最低的scn开始apply 我们可以查询下当前的file header scn:

SQL> select file#,to_char(checkpoint_change#) from v$datafile_header;
 
    
FILE# TO_CHAR(CHECKPOINT_CHANGE#)
--------
-- ----------------------------------------
        
1 42501726792
        
2 42501726792
        
3 42501726801
        
4 42501726801
        
5 42501726801
        
6 42501726801
        
7 42501726792
        
8 40103914365
        
9 42501726792
        
10 42501726801
        
11 42501726801
 ...

看到file 8scn正是oracle需要的scn 对应上面的操作:change 40103914365 generated at 05/23/2012 09:26:36 needed for thread 3 这里的05/23/2012 09:26:36足以说明问题。查看主库的file 8文件发现 change time 05/23/2012,从这里可以说明file 8自从2012-05-23之后从来没有change,对于这种file – BLOCK change0 ,也就是说change scn为上一次的05/23/2012 09:26:36之前的change scn,即所有的块都不满足以上条件,所以对于从64号开始的增量备份,oracle将忽略这个文件的所有blocks从而导致recover之后file header checkpoint scn没有发生变化,当开启redo apply之后oracle仍然从最小的scn开始尝试恢复,从而导致这个诡异的现象,当然这种极端情况是很少出现的,这里我们可以采用rman copy这个filestandby端从而解决这个问题。

eg:

RMANcopy datafile '+DATA/pri/datafile/udata01_16.dbf' to '/data/xxx.dbf';
4个小时之后DG 追上了16天的gap 恢复速度还是不错的 总体来说通过增量备份恢复丢失归档的DG是一个很常规的手法 16天的归档>=4T 如果从带库恢复归档 将是一个漫长的过程

 

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

请登录后发表评论 登录
全部评论

注册时间:2010-11-24

  • 博文量
    132
  • 访问量
    261204