还原数据库RMAN-06023错误的解决方法-CSDN博客

【背景说明】生产数据库需要定期还原到测试环境中，才能保证测试系统数据的准确和真实性。最近在一次进行数据库从正式迁移到测试环境的时候，就发生了一件诡异的现象，虽然问题解决了，但是出现这种奇怪问题的本身并没有找到根本的原因。如果有哪位高手发现了其中问题，请指点。

【环境说明】

操作系统：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、常规方法都用过之后，进行数据库的恢复还是报错，这时候只能寄希望于万能的谷歌，顺便小广告一下通过这个网址可以打开谷歌地址：www.glgoo.com

其中一篇文件如下: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 （请备注数据库类型）

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