ITPub博客

首页 > 数据库 > Oracle > 控制文件自动备份在数据库恢复时带来的小问题

控制文件自动备份在数据库恢复时带来的小问题

原创 Oracle 作者:nisumost 时间:2013-09-26 17:45:12 0 删除 编辑
这个实验是在有备份的情况下进行的,并且部分归档日志在备份后已经被删除掉了,那么先在服务器上执行一个全库的备份:

rman target  /
backup database format '/backup/db_%U.bak' current controlfile format '/backup/cf_%U.bak' plus archivelog format '/backup/ar_%U.bak' delete all input;


备份ok后,把数据文件.控制文件都删掉

cd /oracle/10/oradata/test10g
rm -rf *.dbf
rm -rf *.ctl


将数据库强制停下来

sqlplus /nolog
conn / as sysdba
shutdown abort


将数据库启到nomount状态

startup nomount;


先从备份集中还原控制文件

restore controlfile from '/backup/cf_0uokr5oj_1_1.bak';


将数据库启到mount状态

alter database mount;


还原数据文件

restore database;


恢复数据库

recover database;


这个时候会发现,rman会报出一个错误:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/26/2013 16:19:48
RMAN-06054: media recovery requesting unknown log: thread 1 seq 46 lowscn 644796

在介质恢复的过程中无法找到序列为46的日志

也就是说,出现了日志丢失的情况,但是在实验的过程中并没有删除redo和没有备份的归档,那么问题就应该是出在归档的备份上

先来观察一下之前的备份命令执行时,rman进行备份的步骤:

1.备份现有的归档日志
2.备份数据
3.备份控制文件
4.进行日志切换
5.对日志切换后生成的归档进行备份


很明显,3.4.5步应该就是问题的关键,rman先对控制文件进行了备份,再进行日志的切换,在最后一步才对新生成的归档进行了备份

4.5两步操作的目的是为了对备份期间所产生的数据块变化也进行备份,来保证整个备份的完整性

但是由于先对控制文件进行了备份,后备份的归档,所以最后一次归档的备份信息,在控制文件的备份中是没有记录的

也就导致了rman无法找到这个归档的情况,解决这个问题有2种方法:

1.在备份之初,备份完成后再生成一个控制文件的备份

backup current controlfile format '/backup/cf_%U.bak';

2.让当前的控制文件再加载一次备份集信息

catalog start with '/backup/';


这时再重新做一次数据库恢复就可以顺利完成介质恢复了

recover database;


最后打开数据库即可

这个实验的关键点是备份之后没有手工再生成一个备份和catalog start with 的用法,在一些集成公司或第三方支持服务公司工作的dba,往往
在数据库备份上并不是自己制定的脚本,当故障突然来临时,需要用别人生成的备份来对数据库进行恢复,就有可能遇到这样的问题。




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

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

注册时间:2013-04-27

  • 博文量
    11
  • 访问量
    53193