近日告警日志中出现以下记录:
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.
Leave a Reply