Fail to queue the whole FAL gap in dataguard一例

近日告警日志中出现以下记录： FAL[server]: Fail to queue the whole FAL gap GAP - thread 1 sequence 180-180 DBID 3731271451 branch 689955035 这是一个10.2.0.3的dataguard环境，采用物理备库，归档传输模式；查询metalink发现相关note:

Symptoms

When using ARCH transport, gaps could be flagged in the alert log even though the single log gap was for a log that had not been written at the primary yet. alert.log on primary shows: FAL[server]: Fail to queue the whole FAL gap GAP - thread 1 sequence 63962-63962 DBID 1243807152 branch 631898097 or alert.log on standby shows: Fetching gap sequence in thread 1, gap sequence 63962-63962 Thu Jan 24 14:36:30 2008 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 63962-63962 DBID 2004523329 branch 594300676 FAL[client]: All defined FAL servers have been attempted. v$archive_gap returns no rows SQL> select * from v$archive_gap; no rows selected Cause Bug 5526409 - FAL gaps reported at standby for log not yet written at primary Solution Bug 5526409 is fixed in 10.2.0.4 and 11.1. Upgrade to 10.2.0.4 as Bug 5526409 is fixed in 10.2.0.4. Their is no impact of these messages on the database. You can safely ignore these messages. One-off Patch for Bug 5526409 on top of 10.2.0.3 is available for some platforms. Please check Patch 5526409 for your platform.

该note描述在10.1.0.2-10.2.0.3版本中，在ARCH传输的DataGuard环境中可能出现日志传输gap为单个在primary库中尚未写出的日志，该gap可能会在告警日志中以以上形式标示。

该bug(问题)在版本10.2.0.4和11.1中得到了修复，在10.2.0.3版本中部分平台上有one-off补丁。但实际上该bug(问题)对于主备库不会有任何影响，我们也可以将之忽略。