归档日志间隙是在 Standby 端一系列丢失的重做日志，导致日志应用服务无法继续运行。这通常发生在 Standby 端无法从 Primary Database 接收重做日志或重做日志在 Standby Database 上不可用时。常见原因有:
一旦在 Standby Database 上存在归档间隙，Log Apply Services 就会卡住，直到日志间隙（Gap）被解决，例如。丢失的 Redo 被重新获取并且在 Standby 端可用。然后，日志应用服务可以选中它并继续处理。
有4种方案来解决 Standby Database 上的日志间隙。这些方案在下面讨论。
自动日志间隙解决方案
自动日志间隙解决方案是由日志传输服务自动进行的。它会把当前正在传输的日志和最近收到的日志进行对比，如果有不匹配的情况出现，Standby 端的 RFS 进程就会检测到并自动发送 ARCH-RFS 心跳 Ping 请求来要求发送丢失的日志。这种类型的日志间隙解决方法使用了主数据库上的 log_archive_dest_n 中定义的 Service。另外 ARCH-RFS 心跳 Ping 可以通过对当前的日子序列号进行查询来检测日志间隙。如果存在日志间隙则仍通过ARCH-RFS 心跳 Ping 请求来解决它。在问题得到解决后，会通知日志传输进程（ARCH 或者 LGWR）。对于自动日志间隙解决方案，不需要额外的设置或者监控。
FAL (Fetch Archive Log)日志间隙解决方案
当一个归档日志在 Standby 数据库上被收到或者归档，它就会被注册到 Standby 的控制文件中。（您可以在物理 Standby 数据库上查询 v$archived_log 或在逻辑 Standby 数据库上查询 dba_logstdby_log 来获取这些注册信息）。如果这个文件因为某些原因丢失或者损坏（比如，它被意外删除），FAL 就会被调用来解决日志间隙问题。因为这些缺失的日志文件通常由 Standby 数据库上的日志应用服务检测到。它独立于日志传输服务，并且没有和主库之间的直接链接。要使用 FAL，必须在 Standby 数据库设置一个或者两个（11.2.0 之前的版本）初始化参数：
FAL_SERVER：设置 Oracle Net Service Name（TNS-Alias 或者 Connect Descriptor）指向用来获取丢失的归档日志的数据库。它可以是一个 Data Guard 环境的主库，或者是另一个备库，ArchiveLog Repository- 或者 Far Sync Standby (> Oracle 12.1.0) Database。可以指定多个 Service Names（逗号分隔）。FAL 会顺序的尝试这些数据库来解决日志间隙问题。
FAL_CLIENT (< Oracle 11.2.0)：在 FAL_SERVER 数据库上设置 Oracle Net Service Name（TNS-Alias 或 Connect Descriptor）指向接收 REDO 的 Standby 数据库（比如，它是 FAL_SERVER 数据库需要发送 REDO 到的目标数据库）。确保这个 TNS-Alias 存在于 FAL_SERVER 数据库的 TNSNAMES.ORA 文件中。从 Oracle 11.2.0 开始，这个参数不再需要。但是需要确保 FAL_SERVER 数据库存在一个log_archive_dest_n 指向要解决日志间隙问题的 Standby 数据库。
当 Log ApplyServices 检测到日志间隙问题，它会发送一个 FAL 请求把 FAL_CLIENT 信息（Version > 11.1.0 则为 db_unique_name）给 FAL_SERVER。一个 FAL_SERVER 数据库上的 ARCH-Process 会尝试获取那个日志并发送回 FAL_CLIENT（或者 db_unique_name 对应的 Destination）。如果第一个 FAL_SERVER 无法解决日志间隙，会尝试列表中的下一个 FAL_SERVER。如果所有的 FAL_SERVERs 都无法解决，那么 FAL 请求会失败，并且一个对应的错误信息会写入对应 Standby 数据库的 ALERT.LOG。
为了成功解决日志间隙问题，需要的归档日志应当存在于 FAL_SERVER 数据库（存在于磁盘并且对应的信息同时存在于控制文件中）。
FAL 从 Oracle 9.2.0 开始可用于物理 Standby 数据库，从 Oracle 10.1.0 开始可用于逻辑 Standby 数据库。
手工解决日志间隙
如果日志间隙问题不能被上面提到方式解决，那么可以尝试手工解决。
可以通过查询物理 Standby 数据库的 $archive_gap 或者逻辑 Standby 数据库的 dba_logstdby_log 来确定当前的归档日志间隙，例如：
物理 Standby 数据库
SQL> select * from v$archive_gap;
逻辑 Standby 数据库
SQL> select thread#, sequence# from dba_logstdby_log l where next_change# not in
(select first_change# from dba_logstdby_log where l.thread#=thread#)
order by thread#, sequence#;
现在复制缺失的特定编号的 redo 日志到 Standby 数据库的对应位置。如缺失的日志尚未注册到 Standby 数据库，需要先注册它们才能让 Log Apply Services 处理这些日志文件。可以使用下面的命令注册：
物理 Standby：
SQL> alter database register logfile ‘
逻辑 Standby：
SQL> alter database register logical logfile ‘
在它们被注册后，Log Apply Services 就可以处理了。
使用增量备份前滚（仅适用于物理 Standby）
如果日志间隙无法被上面提到的方式解决，间隙太大需要太久时间才能解决或者丢失的日志无法被找到，您仍然可以通过使用 SCN 增量备份来前滚物理 Standby 数据库。这个功能从 Oracle 10.2.0 开始可以使用。这个功能通过记录最后应用到 Standby 数据库的SCN，然后使用 RMAN 以及当前控制文件的备份来对主库创建一个从那个 SCN 开始的增量备份。
之后首先用增量备份中的控制文件替换 Standby 的控制文件，之后应用增量备份到 Standby 数据库。这是一个把 Standby 数据库同步到最新的主库的状态的最快最简单的方式。因为采取的步骤各个版本都不同，请参考对应版本的 “Oracle Data Guard Concepts and Administration”在线文档中的 “Using RMAN Incremental Backups to Roll Forward a Physical Standby Database”章节。这个章节会有各个版本的详细的一步一步的指令。