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