DG archive gap

什么是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>