10g Data Guard physical standby的Bug 5526409(Fail to queue the whole FAL gap)

用duplicate創建完成physical standby之後，在standby上使用alter database recover managed standby database disconnect from session正準備同步日誌時，主庫與備庫的alert日誌中均出現以下：

primary

----------------------------------------------------

FAL[server]: Fail to queue the whole FAL gap
 GAP - thread 1 sequence 8-8
 DBID 155176457 branch 743338121

 

standby

-----------------------------------------------------

FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 8-8
 DBID 155176457 branch 743338121
FAL[client]: All defined FAL servers have been attempted.

根據以上的錯誤提示，初步判斷為出現了gap，那就看看究竟是哪裡斷了日誌而產生的gap。但是在主庫與備庫上均提示未出現gap，結果如下：

select * from v$archive_gap;

no rows selected

 

這就覺得有點奇怪了，一時有些百思不得其解。去metalink上找找有沒有結果。

原來以上錯誤是因bug所引起的，可是以前做的時候怎麼沒有遇到，每次都成功的。

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.

 

另外，若要想switchover時在primary上發現：

SQL> select protection_level from v$database;

PROTECTION_LEVEL
--------------------
RESYNCHRONIZATION

還伴隨着另一個bug，metalink原文如下：

 

$Archive_dest_status Reports "Destination Has A Gap" [ID 470869.1]
		Modified 15-JUN-2009     Type PROBLEM     Status REVIEWED

 

In this Document
  Symptoms
  Changes
  Cause
  Solution

 

 

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.3
This problem can occur on any platform.

Symptoms

The data guard environment is like that:
Pimray DB:
  - two nodes (two instances)

Standby DB:
  - Single node (single instance)

The configuration works fine until the switchover, currently the Primary is single instance DB and the standby is RAC 2 instances DB.

When query the v$database view:

    SQL> select protection_level from v$database;

  PROTECTION_LEVEL
  -------------------
  RESYNCHRONIZATION

Also, the query result of v$archive_dest_status is:

    SQL> select SYNCHRONIZATION_STATUS from v$archive_dest_status
                where dest_id=2;

    SYNCHRONIZATION_STATUS
    ----------------------
    DESTINATION HAS A GAP

 

Changes

The only changes is a switchover performed.

Cause

The cause of the issue is a false archive log gap detected in V$ARCHIVE_DEST_STATUS
for disabled redo threads.


Bug.6266023: V$ARCHIVE_DEST_STATUS reports false "destination has a gap" for disabled redo thread

Bug.6266023 has been fixed in the patchset 10.2.0.4.

Workaround:
The disabled threads can be re-enabled for just long enough for log switch to occur.
When this happens, both the v$log_history and v$archived_log tables will record a new
entry for the redo thread which will allow the RFS to again bootstrap its gap analysis.

Solution

Download and apply &incFamilyProds=false&flag=search))" target=_blank>patch 6266023.

Workaround:

To implement the solution, please execute the following steps:

1. Logon to the current primary as sysdba

2. Perform the following steps to disable and enable the thread:

SQL> alter database disable thread 2;

Database altered.

SQL> alter system switch logfile;

System altered.

SQL> select protection_level from v$database;

PROTECTION_LEVEL
--------------------
RESYNCHRONIZATION

SQL> alter database enable thread 2;

Database altered.

SQL> alter system switch logfile;

System altered.

SQL> select protection_level from v$database;

PROTECTION_LEVEL
--------------------
MAXIMUM AVAILABILITY

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.

 

不採用RMAN duplicate而採用關閉主庫後，copy所有datafile及redolog至備庫的方法來創建physical standby，則不會出項上述問題。不過從HA的角度出發，還是建議使用RMAN duplicate。