Dataguard的Log Gap检测和处理原理

Dataguard的Log Gap检测和处理原理

 

  提到dataguard的Gap处理机制，大多数人能说出的措施便是设置fal_server和fal_client,从9i开始，
Oracle提供了2种log gap的检测和处理机制。对于gap的处理，fal_*参数在某些情况下并不是必须配置的。 
   1.Automatic Gap Resolution 
   2.FAL Gap Resolution

 

1.Automatic Gap Resolution
    从9i开始，Dataguard就引入了自动日志缺失检测的机制，无需设置任何fal_*参数，Datguard便运行在这种机制下。
当Lgwr和Arch进程发送redo/archive到standby端的时候，当前log sequence会同standby端RFS进程上次接收到的log sequence做比较，如果发现二者有断档，RFS会发送请求到primary端，要求主库传送缺失的日志。从9iR2开始，Automatic gap resolution 功能上得到增强。主库上的ARCH进程会每分钟检查备库上的日志gap情况并做相应处理。 

2.FAL Gap Resolution
    FAL是Fetch Archive Log的缩写，通过配置FALserver和FALclient实现Gap检测的一种机制。当备端的RFS进程收到
archivelog的时候，更新standby的控制文件以记录这些归档信息，一旦MRP发现控制文件被更新，会进行Recover/Apply log。如果MRP发现所需的日志出现缺失或者所需的日志文件不可用(损坏或者被物理移除等)，会通过FAL来发送相应的处理请求。MRP是standby端的恢复进程，不像RFS进程一样与parimary有直接关联，通过FAL的参数配置来主动请求primary处理gap。

 

FAL_Server和fal_client是standby端的参数配置，考虑到switchover的平滑性，可考虑在primary 端也做预先设置。
FAL_SERVER: 指向primary端的Oracle Net service
FAL_CLIENTL: 指向standby端的Oracle Net service   

  

在9iR2以上版本中，Oracle首先尝试使用FAL Gap Resolution 进行GAP处理，当发现FAL机制并没有配置生效的时候，
进而尝试使用Automatic Gap Resolution进行处理。

 

   对于一些cascade dataguard架构，FAL Gap Resolution是更好的gap处理方式。另外，Automatic gap resolution
在某些版本的dg环境下存在bug(比如bug 5929647等)，需要不得不配置FAL参数。