ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 彻底解决rman恢复碰到ora-01152错

彻底解决rman恢复碰到ora-01152错

Linux操作系统 作者:season0891 时间:2016-01-21 13:19:02 0 删除 编辑

说说碰到这个问题的背景。

使用NBU调脚本对oracle进行备份。脚本如下:

RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
    $BACKUP_TYPE
    SKIP INACCESSIBLE
    TAG hot_db_bk_level0
    FILESPERSET 1                #(为了模拟大库的长时间备份,将此参数调为1,原因后面解释
    # recommended format
    FORMAT 'bk_%s_%p_%t'
    DATABASE;
    sql 'alter system archive log current';
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
# backup all archive logs
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
   filesperset 1
   FORMAT 'al_%s_%p_%t'
   ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
#
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
BACKUP
    # recommended format
    FORMAT 'cntrl_%s_%p_%t'
    CURRENT CONTROLFILE;
BACKUP FORMAT 'contrl' CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
}

按照常规方法做异机恢复,recover database报错:

Starting recover at 23-MAR-11

starting media recovery

Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 2 was not restored from a sufficiently old backup
ORA-01110: data file 2: '/u01/oradata/test/undotbs01.dbf'

released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/23/2011 21:55:47
RMAN-06053: unable to perform. media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 52 lowscn 554211 found to restore
RMAN-06025: no backup of log thread 1 seq 51 lowscn 554193 found to restore
RMAN-06025: no backup of log thread 1 seq 50 lowscn 554178 found to restore
RMAN-06025: no backup of log thread 1 seq 49 lowscn 554176 found to restore
RMAN-06025: no backup of log thread 1 seq 48 lowscn 554173 found to restore
RMAN-06025: no backup of log thread 1 seq 47 lowscn 554170 found to restore
RMAN-06025: no backup of log thread 1 seq 46 lowscn 554151 found to restore

下面说说关于这个报错。按照字面意思,file 2 was not restored from a sufficiently old backup ,查了metalink,说是数据文件的scn比控制文件新造成的。我觉得这个ORACLE官方解释存在错误。也就是报错原因跟数据文件的版本压根没关系,我做了如下验证:

SQL> select max(checkpoint_change#) from v$datafile_header; (数据文件最大的现有SCN

MAX(CHECKPOINT_CHANGE#)
-----------------------
                 554055
 SQL>  select checkpoint_change#,current_scn from v$database (控制文件scn)


CHECKPOINT_CHANGE# CURRENT_SCN
------------------ -----------
            554193           0


RMAN> list backup of archivelog all;


List of Backup Sets
===================
………………

61      256.00K    SBT_TAPE    00:00:47     23-MAR-11     
        BP Key: 61   Status: AVAILABLE  Compressed: NO  Tag: TAG20110323T211447
        Handle: al_61_1_746572899   Media:

  List of Archived Logs in backup set 61
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    45      554130     23-MAR-11 554151     23-MAR-11

可以看到,备份下来最新的日志,是45号日志组,scn 554130- 554151 
总结:数据文件最大scn:554055
            控制文件scn:554193。

下面说说我是如何重现这个错的:在备份执行的时候,定时地切换日志,模拟数据库备份时间长,期间发生日志切换的动作。

SQL> alter system switch logfile;

System altered.

SQL> select sequence# from v$log;

 SEQUENCE#
----------
        50
        51
        49

SQL> select first_change# from v$log;

FIRST_CHANGE#
-------------
       554178
       554193
       554176
可以看到,日志已经跑到51号了,但RMAN脚本跑起来,只记录开始备份日志开始那个时间点,有那些日志需要备份,而备份日志过程中,产生的新日志,ORACLE根本不管。在这种情况下,做恢复,必然报ORA-1152错。

研究透彻了报错原因,要启动数据库很简单,刚才看到了,备份下来的最新日志:是45号日志组,scn 554130- 554151 。只要指定恢复到scn:554151,就能按常规的resetlogs打开。

验证:
RMAN> run{
2> allocate channel ch00 type 'SBT_TAPE';
3> SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
4> recover database until scn 554151;
5> alter database open resetlogs;
6> release channel ch00;}

allocated channel: ch00

…………

media recovery complete, elapsed time: 00:00:00
Finished recover at 23-MAR-11

database opened

完成。

回头看看报这个错的原因,其实跟NBU的脚本有关。所有备份的数据类型,写在一个RUN块中,造成备份开始(或开始备份归档以后),oracle统计需要备份的日志文件,未将备份过程中产生的日志算进去,造成日志缺失。信息不一致。(这块我不是很确定)。

归根结底,就是备份数据库的时候,库太繁忙(或者备份时间过长),造成日志切换了。2条思路:1调整备份窗口,空闲时间备份。2我通过以下办法可以解决,由于备份的那个库不算太繁忙(日志切换不快),但备份时间比较长。在第一个run块后,再加一个单独备份归档的run块:

RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=lzl-linux,NB_ORA_SERV=nbu-server';
sql 'alter system archive log current';
BACKUP
   filesperset 10
   FORMAT 'al_%s_%p_%t'
   ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
}

由于之前已经把当天大部分日志都备掉了。我这里再备一次,就我备份2小时内发生的日志切换,10个文件一打包,2通道跑,对于不很繁忙的库,相信不会在这期间切日志了。我就不信你丫再报错。

测试:跟先前测试一样,时刻监控rman输出,在第一个run块备份时,多切几次日志。

在第二个run块,不要切日志。(这样配置在不繁忙的库,很难发生日志切换了)

使用第二个run块调的控制文件备份进行恢复。

经测试,这样备份跟小库情况一样,直接resetlogs就可以打开库。库的状态为第二个run块开始执行的状态。

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

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

注册时间:2008-06-10

  • 博文量
    791
  • 访问量
    1939124