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

[oracle@db61 orcl]$
SQL*Plus: Release 10.2.0.5.0 - Production on Wed Jun 20 14:35:01 2012
Copyright (c) 1982, 2010, Oracle.  All 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

这个库的大概情况为丢失了6月4号至今的所有归档,很容易想到使用standby 的current_scn去作为 起始scn增量备份，对于这里的增量备份出现了一个有趣的现象。看上面的操作,可以知道还是需要scn为40103914365的归档文件,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 8的scn正是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 change为0 ,也就是说change scn为上一次的05/23/2012 09:26:36之前的change scn,即所有的块都不满足以上条件,所以对于从6月4号开始的增量备份,oracle将忽略这个文件的所有blocks从而导致recover之后file header checkpoint scn没有发生变化,当开启redo apply之后oracle仍然从最小的scn开始尝试恢复,从而导致这个诡异的现象,当然这种极端情况是很少出现的,这里我们可以采用rman copy这个file到standby端从而解决这个问题。

eg:

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