还原数据库RMAN-06023错误的解决方法-白红宇

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

【环境说明】

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

其中一篇文件如下:

测试环境运行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这个时间点是上次测试上面恢复的时间记录；

因为这次恢复时间性要求比较紧张，所以没有办法继续在这个环境上面进行恢复测试。先记录该问题，等待下次继续验证；

【解决方法】关于原理性的东西请看链接，解决方法其实很简单

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 （请备注数据库类型）

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