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(问题)对于主备库不会有任何影响,我们也可以将之忽略。

Comments

  1. admin says

    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.

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号