【DG】 DataGuard 中处理archive gap的方法

【DG】 DataGuard 中处理archive gap的方法



DG 中处理archive gap的方法  

====================  

当Primary Database的某些日志没有成功发送到Standby Database, 这时候Standby DB上就会出现归档裂缝( Archive Gap )。


Oracle主要由两个参数处理Archive Gap:


FAL_*  是Fetch Archive Log的缩写,通过配置 FAL_server 和 FAL_client 实现Gap检测的一种机制。从FAL 这个名字可以看出,这个过程是Standby DB主动发起的“取”日志的过程,Standby DB就是FAL_CLIENT. 它是从FAL_server中取这些缺失的Gap, 10g中,这个FAL_server可以是Primary DB, 也可以是其他的Standby DB。如: FAL_SERVER='PR1,ST1,ST2';


       当Lgwr和Arch进程发送redo/archive到standby端的时候,当前log sequence会同standby端RFS进程上次接收到的log sequence做比较,如果发现二者有断档,RFS会根据FAL_Server发送请求,要求主库传送缺失的日志。或者当备端的RFS进程收到archivelog的时候,更新standby的控制文件以记录这些归档信息,一旦MRP发现控制文件被更新,会进行Recover/Apply log。如果MRP发现所需的日志出现缺失或者所需的日志文件不可用(损坏或者被物理移除等),也会通过FAL_Server来发送相应的处理请求。

       MRP是standby端的恢复进程,不像RFS进程一样与parimary有直接关联,通过FAL的参数配置来主动请求primary处理gap。

       从9i以后,一般都不需要手工处理确实的日志,FAL自动会帮我们处理这些问题。 但是,并非我们就完全不用手工处理了,比如,你的磁盘空间爆满,归档日志在传到备库前被转移到其他地方,这种情况下FAL是不能解决问题的,需要手工处理一下。 


解决办法:  

解决gap的方法有两种,方法虽然略有不同,但是原理是相同的

一、gap较少,可以直接将缺少的归档scp到standby,在standby手工注册下即可

二、gap较多,在primary 做基于scn的backup,同时创建一个新的standbycontrolfile,将备份好的backupset ,standbycontrolfile 拷贝的备库的相应目录下,进行restore、recover的操作即可因为这个案例中,standby丢失的归档太多,推荐用第二种方法


///

方法一:手工处理日志GAP的步骤:  


1、在备库检查是否有日志缺失  

SQL> select * from V$ARCHIVE_GAP;  

THREAD#   LOW_SEQUENCE#     HIGH_SEQUENCE#  

------------ ----------------------- ----------------------  

1                  99                               109  

从上面的信息可以看出,备库中缺失了99到109的日志。  

2、在主库中查询缺失的日志的所在路径和名称  

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 99 AND 109 ;  

NAME  

--------------------------------------------------------------------------------  

/u01/archivelog/1_99_626106231.arc  

/u01/archivelog/1_100_626106231.arc  

/u01/archivelog/1_101_626106231.arc  

/u01/archivelog/1_102_626106231.arc  

/u01/archivelog/1_103_626106231.arc  

/u01/archivelog/1_104_626106231.arc  

/u01/archivelog/1_105_626106231.arc  

/u01/archivelog/1_106_626106231.arc  

/u01/archivelog/1_107_626106231.arc  

/u01/archivelog/1_108_626106231.arc  

/u01/archivelog/1_109_626106231.arc  

如果把日志移动到其他路径,则把日志所在路径换成当前实际所在路径。  

3、把日志拷贝到备库上  


4、在备库上手工注册上一步中从主库拷贝来的日志  

SQL> ALTER DATABASE REGISTER LOGFILE '/u01/archivelog/1_99_626106231.arc';  

Database altered.  

......  

SQL> ALTER DATABASE REGISTER LOGFILE '/u01/archivelog/1_109_626106231.arc';  

Database altered.  

5、稍等片刻,观察备库的alert日志信息 :  

Sun Aug 12 20:38:47 2007  

Media Recovery Log /u01/archivelog/1_99_626106231.arc  

Media Recovery Log /u01/archivelog/1_100_626106231.arc  

Media Recovery Log /u01/archivelog/1_101_626106231.arc  

Media Recovery Log /u01/archivelog/1_102_626106231.arc  

......  

从以上信息,可以看出之前注册的日志已经被正常应用。或者查询视图v$archived_log的applied字段  

6、检查备库是否还有日志GAP  

SQL> select * from V$ARCHIVE_GAP;  

no rows selected  

如果有行返回,则重复2-5步,直到查询结果是"no rows selected"。  

如果日志只是临时移动到其他地方,过后会再移回原路径,则不用这么大费周折手工去手工处理了,把日志拷回原处后FAL会自动处理GAP。  


//  

方法二:操作流程提纲:  

(1)      standby 取消recover

SQL> select * from v$archive_gap ;

SQL> alter database recover managed standby database cancel;


(2)      在主库v$archived_log查询gap中LOW_SEQUENCE#-1对应的scn(即:first_change#)

SQL>select THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#from v$archived_log where SEQUENCE#=98;

  THREAD#    SEQUENCE#   FIRST_CHANGE#    NEXT_CHANGE#

  ---------- ---------- ------------- ------------

         1      481     542543    551725


(3)      在primary做基于该scn的增量备份

RMAN> run {

2> allocate channel c1 device type disk;

3> allocate channel c2 device type disk;

4> backup incremental from scn 542543 database format '/oradata/bak/ora_scn_%U.bak';    #incremental单词不要写错

5> release channel c1;

6> }


(4)      在primary创建新的standby controlfile

SQL> alter database create standby controlfile as '/oradata/bak/control.ctl';


(5)      将增量的备份集和创建好的standby controlfile 拷贝的备库


(6)      备库shutdown

SQL> shutdownimmediate


(7)      使用新的standby controlfile 启动备库到mount

SQL> startup mount;


(8)      Standby 做recover

RMAN> catalog start with '/oradata/bak/ora_scn_05ohoqvu_1_1';     ###放在standby的增量备份的备份集

RMAN> recover database noredo;



(9)      验证结果

Standby 执行接收并恢复日志操作

SQL> alterdatabase recover managed standby database disconnect from session;

SQL> select * fromv$archive_gap;

no rows selected

SQL> select THREAD#,max(SEQUENCE#) from v$archived_log group by THREAD#;

   THREAD# MAX(SEQUENCE#)

---------- --------------

         1           3729

 

Primary端验证结果

 

SQL> select THREAD# ,max(SEQUENCE#) from v$archived_log  group by THREAD#;

   THREAD# MAX(SEQUENCE#)

--------- --------------

1                                      3729


Primary进行日志切换,查看standby告警日志。


  

上一篇:【12c】12c RMAN新特性之通过网络远程恢复数据库(RESTORE/Recover from Service)


下一篇:【DG】DG之Switchover和Failover的区别