【背景說明】生產資料庫需要定期還原到測試環境中，才能保證測試系統資料的準確和真實性。最近在一次進行資料庫從正式遷移到測試環境的時候，就發生了一件詭異的現象，雖然問題解決了，但是出現這種奇怪問題的本身並沒有找到根本的原因。如果有哪位高手發現了其中問題，請指點。

【環境說明】

作業系統：Centos 5.7
ORACLE資料庫版本：11.2.0.1
備份方式：rman+network+dd

【操作思路】

1、對當前正式庫的資料庫進行全備；

2、在測試資料庫上面進行控制檔案的恢復；

3、在測試資料庫上面進行資料庫的restore和recover操作；

注：為了操作方便測試環境和正式環境資料庫的SID、檔案系統的位置都是一樣的，所以引數檔案的恢復就可以不用進行了；

【操作步驟】

1、進行控制檔案的恢復（因為是備份到DD，device type：sbt_tape)

run{

allocate channel ch11 device TYPE 'SBT_TAPE';

SEND DEVICE TYPE 'SBT_TAPE' 'NSR_ENV=(NSR_SERVER=erver01,NSR_CLIENT= jbdb)';

restore controlfile from 'JBDB_CONTROL_33127_1_20150724';

release channel ch11;

}

當前步驟順利完成；

2、進行資料庫的恢復操作

RMAN> run{
allocate channel ch11 device TYPE 'SBT_TAPE';
SEND DEVICE TYPE 'SBT_TAPE' 'NSR_ENV=(NSR_SERVER=bkserver01,NSR_CLIENT= jbdb)';
restore database;
release channel ch11;
}2> 3> 4> 5> 6>

allocated channel: ch11
channel ch11: SID=129 device type=SBT_TAPE
channel ch11: NMDA Oracle v1.2.0

sent command to channel: ch11

Starting restore at 24-JUL-15

released channel: ch11
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 07/24/2015 10:43:03
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

資料庫出現了報錯資訊，報錯資訊顯示找不到備份檔案，所以對單個備份檔案進行了確認操作

【問題分析】對當前的備份進行校驗

1、在執行之前進行了crosscheck backupset的操作；

RMAN> list backup of datafile 1;

using target database control file instead of recovery catalog

List of Backup Sets
===================
BS Key Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
32862   Full    736.25M    SBT_TAPE    00:00:32     21-JUL-15
        BP Key: 32862   Status: AVAILABLE Compressed: NO Tag: TAG20150721T040055
        Handle: JBDB_32871_1_20150721   Media: B99010
List of Datafiles in backup set 32862
File LV Type Ckp SCN    Ckp Time Name
---- -- ---- ---------- --------- ----
1       Full 17464595821 21-JUL-15 /oracle/oradata/JBDB/system01.dbf

BS Key Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
32929   Full    736.25M    SBT_TAPE    00:00:33     22-JUL-15
        BP Key: 32929   Status: AVAILABLE Compressed: NO Tag: TAG20150722T040100
        Handle: JBDB_32938_1_20150722   Media: B99017
List of Datafiles in backup set 32929
File LV Type Ckp SCN    Ckp Time Name
---- -- ---- ---------- --------- ----
1       Full 17465609958 22-JUL-15 /oracle/oradata/JBDB/system01.dbf

BS Key Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
32994   Full    736.25M    SBT_TAPE    00:00:37     23-JUL-15
        BP Key: 32994   Status: AVAILABLE Compressed: NO Tag: TAG20150723T040100
        Handle: JBDB_33003_1_20150723   Media: B99010
List of Datafiles in backup set 32994
File LV Type Ckp SCN    Ckp Time Name
---- -- ---- ---------- --------- ----
1       Full 17466572756 23-JUL-15 /oracle/oradata/JBDB/system01.dbf

BS Key Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
33056   Full    736.25M    SBT_TAPE    00:00:34     24-JUL-15
        BP Key: 33056   Status: AVAILABLE Compressed: NO Tag: TAG20150724T040102
        Handle: JBDB_33065_1_20150724   Media: B99017
List of Datafiles in backup set 33056
File LV Type Ckp SCN    Ckp Time Name
---- -- ---- ---------- --------- ----
1       Full 17467592728 24-JUL-15 /oracle/oradata/JBDB/system01.dbf

顯示當前datafile 1的所有備份都是有效的；

2、常規方法都用過之後，進行資料庫的恢復還是報錯，這時候只能寄希望於萬能的谷歌，順便小廣告一下透過這個網址可以開啟谷歌地址：http://blog.csdn.net/leishifei/article/details/6430057

測試環境執行list incarnation的記錄；

RMAN> list incarnation;

List of Database Incarnations
DB Key Inc Key     DB Name       DB ID            STATUS        Reset SCN         Reset Time
------- -------       --------      -------------    --------        ----------       ---------------
1            1              JBDB       1285701182      PARENT           1                 15-AUG-09
2            2              JBDB       1285701182      PARENT         945184          12-JUL-13
3            3              JBDB       1285701182     CURRENT    16560880455     26-JUN-15

測試資料庫顯示進行了三次的resetlog是的操作；

正式環境執行list incarnation的記錄

RMAN> list incarnation;

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- --------- ------------- ---------- ----------- ------------

1 1 JBDB 1285701182 PARENT 1 15-AUG-09
2 2 JBDB 1285701182 PARENT 945184 12-JUL-13

【疑問】正式的資料庫顯示只有兩個的Reset SCN的記錄，而測試資料庫的控制檔案是從正式環境還原出來的，但是顯示了三次記錄,且26-JUN-15這個時間點是上次測試上面恢復的時間記錄；

因為這次恢復時間性要求比較緊張，所以沒有辦法繼續在這個環境上面進行恢復測試。先記錄該問題，等待下次繼續驗證；

【解決方法】關於原理性的東西請看連結http://blog.csdn.net/henrybai/article/details/38037255，解決方法其實很簡單

RMAN> reset database to incarnation 2;

RMAN>

run{
allocate channel ch11 device TYPE 'SBT_TAPE';
SEND DEVICE TYPE 'SBT_TAPE' 'NSR_ENV=(NSR_SERVER=server01,NSR_CLIENT=jbdb)';
restore database from tag=TAG20150724T040102;
release channel ch11;
}2> 3> 4> 5> 6>

allocated channel: ch11
channel ch11: SID=6 device type=SBT_TAPE
channel ch11: NMDA Oracle v1.2.0

sent command to channel: ch11

Starting restore at 24-JUL-15

channel ch11: starting datafile backup set restore
channel ch11: specifying datafile(s) to restore from backup set
channel ch11: restoring datafile 00005 to /oracle/oradata/jbdb/EKP01
channel ch11: reading from backup piece JBDB_33059_1_20150724

顯示整個資料庫可以進行正常的恢復了。

【問題的思考】整個恢復已經經過多次的恢復，也做了詳細的操作文件，但是這次恢復就是出現了莫名的錯誤。不過經過查詢資料還是把問題解決了。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

本文作者：JOHN，某上市公司DBA，業餘時間專注於資料庫的技術管理，從管理的角度去運用技術。

技術部落格：獵人筆記資料庫技術群：367875324 （請備註資料庫型別）

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

還原資料庫RMAN-06023錯誤的解決方法

相關文章