ITPub博客

首页 > 数据库 > Oracle > 还原数据库RMAN-06023错误的解决方法

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

Oracle 作者:wzq609 时间:2015-07-25 11:15:57 0 删除 编辑

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

 

【环境说明】

  • 操作系统: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 (请备注数据库类型)

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12679300/viewspace-1750350/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2013-06-16

  • 博文量
    173
  • 访问量
    2893055