什么是archive gap
Archive Gap就是standby端日志应用的过程中丢失的一段范围的redo.典型的发生在standby端不能接收primary的redo信息或者接收后不能应用这些redo.
一旦出现GAP，则standby端的Log Apply Services将会暂停，直到Gap解决后恢复正常。
产生Archive Gap的可能原因：
- 网络或者日志传输服务中断
- standby故障
- 日志传输服务配置错误
- standby端I/O异常
- 在archivelog应用到standby之前被手工删除
- 带宽不足
GAP的处理
Automatic Gap Resolution
自动Gap处理由Log Transport Services自动执行。11.2开始，通过比较当前要传输的日志和standby最后接收到的日志信息，如果中间有丢失的redo,将会通过ARCH-RFS Heartbeat Ping机制自动向primary请求丢失的log序列。这种Gap解决类型采用参数LOG_ARCHIVE_DEST_n配置的SERVICE定义。ARCH-RFS Heartbeat Ping执行current和Gap之间日志序列的顺序询问，发现一个解决一个。Gap解决完成后，ARCH/LGWR进程将会被通知Gap已解决，然后继续传输redo.
FAL(Fetch Archive Log) Gap Resolution
Standby接收到archivelog，或者standby redolog接收redo信息后，将会注册到standby controlfile中。如果由于某种原因丢失或者其中某个redo不可用，FAL将会请求执行GAP解决。使用FAL，则需要设置相关的参数。
FAL_SERVER:执行向哪个DB(primary/standby)请求archivelog的TNS-Alias或连接串。可以指定多个，FAL将会顺序尝试这些TNS-Alias请求archivelog解决Gap.
FAL_CLIENT: 11.2开始废弃。11.1之前指定standby的TNS-Alias，11.1指定为standby的DB_UNIQUE_NAME,用来响应FAL_SERVER.
当Log Apply Services发现Gap,将会发送FAL请求到FAL_SERVER.FAL_SERVER的ARCH进程
尝试获得并发送请求的日志序列到FAL_CLIENT。如果FAL_SERVER指定的TNS-Alias中第一个请求不成功，将会顺序的尝试向第二个TNS请求。如果轮询一遍后均请求失败，则在alert log中抛出错误。
FAL机制从9.2 physical standby,10.1的logical standby开始出现。
Manual Gap Resolution
当Gap不能自动解决时，则需要手工去解决。
物理standby通过查询V$ARCHIVE_GAP视图查看当前的GAP,此视图存在一些已知BUG。
SQL> select * from v$archive_gap;
可通过以下SQL查询是否存在GAP:
set lines 200 pages 100
column db_name format a9
column database_role format a13
column thread# format 9999
break on thread# skip 1
select db_name,thread#,database_role,sequence# from
(select name db_name from v$database),
(select ‘Primary‘ database_role,thread#,sequence# from (select unique thread#, max(sequence#) over (partition by thread#) as sequence# from v$archived_log where standby_dest=‘NO‘ and archived=‘YES‘))
union all
select db_name,thread#,database_role,sequence# from
(select name db_name from v$database),
(select ‘Standby‘ database_role,thread#,sequence# from (select unique thread#, max(sequence#) over (partition by thread#) as sequence# from v$archived_log where standby_dest=‘YES‘ and archived=‘YES‘))
order by thread#,database_role;
需要注意的是，有的redo已经在standby内存中应用，还未写入磁盘，此时在primary端查询的APPLIED仍然为NO,只需要在standby端刷新一下buffer_cache即可。
SQL> alter system flush buffer_cache;
如果存在GAP,则拷贝GAP日志序列到standby，并手工注册。
SQL> alter database register logfile ‘log-file‘;
Roll forward using Incremental Backup(Physical standby only)
从10.2开始,如果上述方法均不能解决Gap，则可以采用指定SCN的增量备份解决Gap.
查询standby最后应用日志的SCN,在primary指定该SCN做一个RMAN增量备份和for standby的controlfile备份，在standby端，恢复新的standby controlfile,然后应用增量备份。
可以参考ONLINE Document<Oracle Data Guard Concepts and Administration>
<Using RMAN Incremental Backups to Roll Forward a Physical Standby Database>章节。
MOS(文档 ID 836986.1)<Steps to perform for Rolling Forward a Physical Standby Database using RMAN Incremental Backup>