ITPub博客

首页 > 数据库 > Oracle > RMAN恢复出错的排查

RMAN恢复出错的排查

原创 Oracle 作者:wailon 时间:2015-09-17 15:31:26 0 删除 编辑
环境描述:
由于业务需要,在系统设置了定时作业,从正式库的增量备份(包括0级【星期六】和1级备份【其他时间】),复制到测试环境,然后进行还原恢复。该作业一直运行正常,主要脚本如下:
-------------------------------------------------------------------------------------------------------
rman   auxiliary /  log /rmanbak/recover_$BACKUP_DATE.log  << EOF
run{
allocate auxiliary channel c1 type disk;
allocate auxiliary channel c2 type disk;
DUPLICATE  DATABASE TO  ractest BACKUP LOCATION '/rmanbak/';
}
exit
EOF
-------------------------------------------------------------------------------------------------------
突然这两周发现,到最后恢复数据库时,都出现类似如下的错误信息

-- 以下是报错信息,找不到对应的归档日志
starting media recovery

unable to find archived log
archived log thread=1 sequence=107879
Oracle instance started

Total System Global Area   37413179392 bytes

Fixed Size                     2234296 bytes
Variable Size              17582524488 bytes
Database Buffers           19730006016 bytes
Redo Buffers                  98414592 bytes

contents of Memory Script:
{
   sql clone "alter system set  db_name =
 ''ERPRAC'' comment=
 ''Reset to original value by RMAN'' scope=spfile";
   sql clone "alter system reset  db_unique_name scope=spfile";
   shutdown clone immediate;
}
executing Memory Script

Errors in memory script
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01507: database not mounted
ORA-06512: at "SYS.X$DBMS_RCVMAN", line 13371
ORA-06512: at line 1
RMAN-03015: error occurred in stored script Memory Script
RMAN-20000: abnormal termination of job step
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 107879 and starting SCN of 41331325458
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/17/2015 06:54:52
RMAN-05501: aborting duplication of target database

临时解决方法:
-- 使用recover database using backup controlfile unitl cancel恢复数据库,根据提示信息,从源库复制对应的归档日志到目标库,应用后就可以恢复成功了。

最终原因及方法:
经过排查后发现,缺失的这部分归档日志都是在1级增量备份开始之后产生的,但为什么没有备份并传到目标库主机呢?
-- 增量备份的其中一部分脚本如下,其中这一句引起了我的注意
backup archivelog from time "to_date(to_char(sysdate,'yyyy-mm-dd')||' 00:50:00','yyyy-mm-dd hh24:mi:ss')" until time "sysdate"  format '/rmanbak/${BACKUP_DATE}/archivelog/arch_level_1_%d_%T_%U';

意思是只备份从0点50分开始,到开始备份的所有的归档日志。

为什么会不备份这一段时间的归档日志呢?估计是基于数据量的考虑,所以排除了。
那为什么之前的备份可以正常还原呢?

突然间,想起前几天修改过备份任务的开始时间,从凌晨1点改成凌晨0点开始执行。
从以下的备份视图可以看出,后面那几天都是从0点开始执行备份的。

为什么原来没有报错,因为已经备份了所需的归档日志。
现在要做的就是把备份开始时间调整回去,改到凌晨1点开始执行,之后的还原就不再有问题了。





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

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2013-11-08

  • 博文量
    51
  • 访问量
    291509