徹底解決rman恢復碰到ora-01152錯

說說碰到這個問題的背景。

使用NBU調指令碼對oracle進行備份。指令碼如下：

RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
    $BACKUP_TYPE
    SKIP INACCESSIBLE
    TAG hot_db_bk_level0
    FILESPERSET 1                #（為了模擬大庫的長時間備份，將此引數調為1，原因後面解釋）
    # recommended format
    FORMAT 'bk_%s_%p_%t'
    DATABASE;
    sql 'alter system archive log current';
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
# backup all archive logs
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
   filesperset 1
   FORMAT 'al_%s_%p_%t'
   ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
#
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
    # recommended format
    FORMAT 'cntrl_%s_%p_%t'
    CURRENT CONTROLFILE;
BACKUP FORMAT 'contrl' CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
}

按照常規方法做異機恢復，recover database報錯：

Starting recover at 23-MAR-11

starting media recovery

Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 2 was not restored from a sufficiently old backup
ORA-01110: data file 2: '/u01/oradata/test/undotbs01.dbf'

released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/23/2011 21:55:47
RMAN-06053: unable to perform. media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 52 lowscn 554211 found to restore
RMAN-06025: no backup of log thread 1 seq 51 lowscn 554193 found to restore
RMAN-06025: no backup of log thread 1 seq 50 lowscn 554178 found to restore
RMAN-06025: no backup of log thread 1 seq 49 lowscn 554176 found to restore
RMAN-06025: no backup of log thread 1 seq 48 lowscn 554173 found to restore
RMAN-06025: no backup of log thread 1 seq 47 lowscn 554170 found to restore
RMAN-06025: no backup of log thread 1 seq 46 lowscn 554151 found to restore

下面說說關於這個報錯。按照字面意思，file 2 was not restored from a sufficiently old backup ，查了metalink，說是資料檔案的scn比控制檔案新造成的。我覺得這個ORACLE官方解釋存在錯誤。也就是報錯原因跟資料檔案的版本壓根沒關係，我做了如下驗證：

SQL> select max(checkpoint_change#) from v$datafile_header; （資料檔案最大的現有SCN）

MAX(CHECKPOINT_CHANGE#)
-----------------------
                 554055
 SQL>  select checkpoint_change#,current_scn from v$database (控制檔案scn)

CHECKPOINT_CHANGE# CURRENT_SCN
------------------ -----------
            554193           0

RMAN> list backup of archivelog all;

List of Backup Sets
===================
………………

61      256.00K    SBT_TAPE    00:00:47     23-MAR-11     
        BP Key: 61   Status: AVAILABLE  Compressed: NO  Tag: TAG20110323T211447
        Handle: al_61_1_746572899   Media:

  List of Archived Logs in backup set 61
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    45      554130     23-MAR-11 554151     23-MAR-11

可以看到，備份下來最新的日誌，是45號日誌組，scn 554130- 554151 
總結：資料檔案最大scn：554055
            控制檔案scn：554193。

下面說說我是如何重現這個錯的：在備份執行的時候，定時地切換日誌，模擬資料庫備份時間長，期間發生日誌切換的動作。

SQL> alter system switch logfile;

System altered.

SQL> select sequence# from v$log;

 SEQUENCE#
----------
        50
        51
        49

SQL> select first_change# from v$log;

FIRST_CHANGE#
-------------
       554178
       554193
       554176
可以看到，日誌已經跑到51號了，但RMAN指令碼跑起來，只記錄開始備份日誌開始那個時間點，有那些日誌需要備份，而備份日誌過程中，產生的新日誌，ORACLE根本不管。在這種情況下，做恢復，必然報ORA-1152錯。

研究透徹了報錯原因，要啟動資料庫很簡單，剛才看到了，備份下來的最新日誌：是45號日誌組，scn 554130- 554151 。只要指定恢復到scn：554151，就能按常規的resetlogs開啟。

驗證：
RMAN> run{
2> allocate channel ch00 type 'SBT_TAPE';
3> SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
4> recover database until scn 554151;
5> alter database open resetlogs;
6> release channel ch00;}

allocated channel: ch00

…………

media recovery complete, elapsed time: 00:00:00
Finished recover at 23-MAR-11

database opened

完成。

回頭看看報這個錯的原因，其實跟NBU的指令碼有關。所有備份的資料型別，寫在一個RUN塊中，造成備份開始（或開始備份歸檔以後），oracle統計需要備份的日誌檔案，未將備份過程中產生的日誌算進去，造成日誌缺失。資訊不一致。（這塊我不是很確定）。

歸根結底，就是備份資料庫的時候，庫太繁忙（或者備份時間過長），造成日誌切換了。2條思路：1調整備份視窗，空閒時間備份。2我透過以下辦法可以解決，由於備份的那個庫不算太繁忙（日誌切換不快），但備份時間比較長。在第一個run塊後，再加一個單獨備份歸檔的run塊：

RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
sql 'alter system archive log current';
BACKUP
   filesperset 10
   FORMAT 'al_%s_%p_%t'
   ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
}

由於之前已經把當天大部分日誌都備掉了。我這裡再備一次，就我備份2小時內發生的日誌切換，10個檔案一打包，2通道跑，對於不很繁忙的庫，相信不會在這期間切日誌了。我就不信你丫再報錯。

測試：跟先前測試一樣，時刻監控rman輸出，在第一個run塊備份時，多切幾次日誌。

在第二個run塊，不要切日誌。（這樣配置在不繁忙的庫，很難發生日誌切換了）

使用第二個run塊調的控制檔案備份進行恢復。

經測試，這樣備份跟小庫情況一樣，直接resetlogs就可以開啟庫。庫的狀態為第二個run塊開始執行的狀態。