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

前幾天一起和同事處理過一起歸檔丟失的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 如果從帶庫恢復歸檔 將是一個漫長的過程

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/758322/viewspace-733651/，如需轉載，請註明出處，否則將追究法律責任。