提到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参数。