近日告警日志中出现以下记录：
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.
Hdr: 5526409 10.2.0.2 RDBMS 10.2.0.2 DATAGUARD_PSBY PRODID-5 PORTID-226
Abstract: FAL[CLIENT]: FAILED TO REQUEST GAP SEQUENCE BUT NO GAPS FOUND
PROBLEM:
——–
The customer has two node RAC primary and a physical standby that is not RAC.
The logs are transported automatically and gets applied normally, but the
standby
alert.log always shows a gap although the diag report does not.
A typical message seen in the standby alert.log is
Fetching gap sequence in thread 2, gap sequence 1190-1190
Wed Aug 2 17:51:26 2006
FAL[client]: Failed to request gap sequence
GAP – thread 2 sequence 1190-1190
DBID 2004523329 branch 594300676
FAL[client]: All defined FAL servers have been attempted.
The log sequence #1190 in thread 2 is the current log in the second instance
of
the primary. When the log sequence #1190 gets archived and is transferred to
the standby, then the GAP message will ask for #1191.
DIAGNOSTIC ANALYSIS:
——————–
WORKAROUND:
———–
none
RELATED BUGS:
————-
REPRODUCIBILITY:
—————-
TEST CASE:
———-
STACK TRACE:
————
SUPPORTING INFORMATION:
———————–
24 HOUR CONTACT INFORMATION FOR P1 BUGS:
—————————————-
DIAL-IN INFORMATION:
——————–
IMPACT DATE:
————
I have reproduced the FAL errors on an internal cluster
My setup is as follows:
o. 10.2.0.2 on Linux x86
o. 2 node RAC primary:
– dbname : RACDB
– Instance 1 name: RACDB1
– Instance 2 name: RACDB2
o. Single instance physical standby
The relevant initialisation and network parameters required to reproduce the
errors are:
o. Primary:
*.log_archive_config=’dg_config=(PSTBY)’
*.log_archive_dest_1=’service=pstby ARCH SYNC NOAFFIRM delay=0 OPTIONAL
max_failure=0 max_connections=1 reopen=300
db_unique_name=”PSTBY” register net_timeout=180
valid_for=(online_logfile,primary_role)’
*.log_archive_format=’%t_%s_%r.dbf’
RACDB1.remote_listener=’LISTENER_RACDB2′
RACDB2.remote_listener=’LISTENER_RACDB1′
o. Standby:
*.db_unique_name=’pstby’
*.fal_client=pstby
*.fal_server=racdb
*.log_archive_config=’dg_config=(RACDB)’
The standby is using online logfiles and recovery is being done in real-time
mode
o. full init.ora files
o. Network files (listener.ora, tnsnames.ora, sqlnet.ora) which describe
the service names PSTBY and RACDB
o. Alert logs showing the error
If you create a setup as I have done then you should be able to reproduce the
FAL errors
Note, although the dataguard broker is being started, I have not created
a dataguard configuration
REDISCOVERY INFORMATION:
If using ARCH transport and messages such as;
Fetching gap sequence in thread 2, gap sequence 1190-1190
appear in the alert log of a physical standby but the sequnce number quoted has
not yet been archived at the primary, then this bug is being hit.
WORKAROUND:
Ignore the message as it is benign.
RELEASE NOTES:
]]When using ARCH transport, gaps could be flagged in the standby
]]alert log even though the single log gap was for a log that had
]]not been written at the primary yet.