解决方案 »

  1.   

    Data Guard出现gap sequence修复
    发表于 2011 年 07 月 05 日 由 惜分飞 联系:手机(13429648788) QQ(107644445)链接:http://www.xifenfei.com/1176.html标题:Data Guard出现gap sequence修复作者:惜分飞©版权所有[文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.]一、出现gap sequence现象
    备库
    Fetching gap sequence in thread 1, gap sequence 710-716
    Tue May 31 15:02:38 2011
    FAL[client]: Failed to request gap sequence
     GAP - thread 1 sequence 710-716
     DBID 3240478808 branch 746916894
    FAL[client]: All defined FAL servers have been attempted.
    -------------------------------------------------------------
    Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
    parameter is defined to a value that is sufficiently large
    enough to maintain adequate log switch information to resolve
    archivelog gaps.
    -------------------------------------------------------------主库
    Tue May 31 13:50:47 2011
    FAL[server]: Fail to queue the whole FAL gap
     GAP - thread 1 sequence 710-716
     DBID 3240478808 branch 746916894二、修复操作
    1、查询备库的scn
    SQL> SELECT CURRENT_SCN FROM V$DATABASE;
    CURRENT_SCN
    -----------
        1154337
    --在出现意外datafile header scn不一致的时候,需要根据提示归档日志,找出最小scn2、确定主库是否添加数据文件
    SQL> select FILE#,name from v$datafile where CREATION_CHANGE#> =1154337;
    no rows selected确定主库在这个scn之后是否有添加数据文件,如果添加文件,需要手工在备库添加3、备库停止日志应用
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;4、主库增量备份并传输到备库上
    主库进行增量备份
    RMAN> BACKUP INCREMENTAL FROM SCN  1154337 DATABASE
    FORMAT '/home/oracle/xff_%U' tag 'XIFENFEI';
    [oracle@localhost ~]$ scp xff* 192.168.1.30:/home/oracle/rman说明:主库之前必须要做过rman的全备(没有全备的库,基于scn的增量备份也能够成功)5、备库上进行恢复
    RMAN> CATALOG START WITH '/home/oracle/rman';
    RMAN> RECOVER DATABASE NOREDO;说明:CATALOG START WITH是10g及其以后版本中才存在功能,没有该功能可以采用catalog或者复制主库的控制文件,rman备份放置和主库备份时相同目录实现。6、主库上创建standby controlfile文件并传输到备库
    RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY
    FORMAT '/home/oracle/xff_ctl.bck';
    [oracle@localhost ~]$ scp xff_ctl.bck 192.168.1.30:/home/oracle/rman创建standby controlfile两步可以需要根据实际情况考虑,大多数情况下不需要7、备库恢复控制文件
    RMAN> shutdown;
    RMAN> STARTUP NOMOUNT;
    RMAN> RESTORE STANDBY CONTROLFILE FROM '/home/oracle/rman/xff_ctl.bck';
    RMAN> alter database mount;8、清空备库日志组
    SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
    注:如果采用了standby log模式,不需要清空,如果清空会出现
    SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
    ALTER DATABASE CLEAR LOGFILE GROUP 1
    *
    ERROR at line 1:
    ORA-19527: physical standby redo log must be renamed
    ORA-00312: online log 1 thread 1: '/u01/oradata/xienfei/redo01.log'说明:如果没有采用standby log模式,有几组需要清空几组9、备库重设flashback
    SQL> ALTER DATABASE FLASHBACK OFF;
    SQL> ALTER DATABASE FLASHBACK ON;10、备库重新接收并应用日志
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;三、修复成功标志
    1、sql中操作
    在主库中执行alter system switch logfile;
    分别主备库中执行select max(sequence#) from v$archived_log;如果一致标示修复成功2、通过alert文件
    主库
    PING[ARC0]: Error 3113 when pinging standby xff.
    Tue May 31 14:11:51 2011
    Thread 1 advanced to log sequence 719
      Current log# 3 seq# 719 mem# 0: /u01/oradata/xienfei/redo03.log
    Tue May 31 14:20:05 2011
    Thread 1 advanced to log sequence 720
      Current log# 1 seq# 720 mem# 0: /u01/oradata/xienfei/redo01.log
    Tue May 31 14:20:16 2011
    ARC0: Standby redo logfile selected for thread 1 sequence 719 for destination LOG_ARCHIVE_DEST_2备库
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
    Tue May 31 15:30:37 2011
    Attempt to start background Managed Standby Recovery process (xff)
    MRP0 started with pid=18, OS id=14704
    Tue May 31 15:30:37 2011
    MRP0: Background Managed Standby Recovery process started (xff)
    Managed Standby Recovery not using Real Time Apply
     parallel recovery started with 2 processes
    Media Recovery Log /u01/archive/1_718_746916894.arc
    Tue May 31 15:30:43 2011
    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
    Tue May 31 15:30:52 2011
    RFS[1]: Successfully opened standby log 4: '/u01/oradata/xienfei/s_redo1.log'
    Media Recovery Log /u01/archive/1_719_746916894.arc
    Media Recovery Waiting for thread 1 sequence 720    使用rman备份做Data Guard
        因v$archived_log视图记录异常导致dg MRP进程异常
        Oracle 9I Data Guard配置
        ORACLE 12C Windows-Linux 部署DATAGURAD
        11G RAC TO 11G RAC ADG SWITCHOVER
        rman创建Standby Data Guard
        修改dataguard主库redo组数和大小
        Data Guard Failover 处理
      

  2.   

    ORACLE是那个版本的,如果是9I,那么你只能重做备库,10G以上,有一个解决方法,你可以百度下
      

  3.   

    这种情况我的处理方式有两种:
    一:正常情况下生产主库都有做rman备份,通过rman备份把缺少的归档日志还原到原来的位置,oracle会自动把这个归档传过去应用.     set archivelog destination to '/xxxx';
           restore archivelog  from logseq xxxxx;
    当然也可以手动把恢复过来的归档日志复制到备库,然后手动注册.
         alter system register physical logfile '/xxxx';
    二.如果生产主库rman中没有对应的归档日志,重建备库了.
      

  4.   

    9 好象只能干掉重建, 据说 10 R2 开始可以按 scn 倒腾一下子,没实际实验过。
      

  5.   

    OKokOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOK
      

  6.   

     重建DG 没其他办法,你的DG已经失效了
      

  7.   


    这个就是10G及其以上版本才可以的,基于scn的增量备份恢复dg