dg归档gap的处理

常见原因有:

• 网络连接断开或者日志传输服务停止
• Standby Database 不可用
• 日志传输服务的配置错误
• Standby 端的 IO 问题
• 归档日志在应用到 Standby 前被手工删除
• Primary 和 Standby 之间的网络带宽不足

解决方案有4种


1 自动日志间隙解决方案（相当于没说）
自动日志间隙解决方案是由日志传输服务自动进行的。它会把当前正在传输的日志和最近收到的日志进行对比，如果有不匹配的情况出现，Standby 端的 RFS 进程就会检测到并自动发送 ARCH-RFS 心跳 Ping 请求来要求发送丢失的日志。这种类型的日志间隙解决方法使用了主数据库上的 log_archive_dest_n 中定义的 Service。另外 ARCH-RFS 心跳 Ping 可以通过对当前的日子序列号进行查询来检测日志间隙。如果存在日志间隙则仍通过ARCH-RFS 心跳 Ping 请求来解决它。在问题得到解决后，会通知日志传输进程（ARCH 或者 LGWR）。对于自动日志间隙解决方案，不需要额外的设置或者监控。

2 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 会顺序的尝试这些数据库来解决日志间隙问题

3 手工解决日志间隙 （重点）
如果日志间隙问题不能被上面提到方式解决，那么可以尝试手工解决


物理 Standby 数据库
SQL> select * from v$archive_gap;
现在复制缺失的特定编号的 redo 日志到 Standby 数据库的对应位置。如缺失的日志尚未注册到 Standby 数据库，需要先注册它们才能让 Log Apply Services 处理这些日志文件。可以使用下面的命令注册：
SQL> alter database register logfile '/arch/1_243_1065253017.dbf';
在它们被注册后，Log Apply Services 就可以处理了

4 使用增量备份前滚（仅适用于物理 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”章节。这个章节会有各个版本的详细的一步一步的指令

参考：Data Guard 日志间隙检测及解决方案 (Doc ID 2403964.1)