IBM Support

IC90020: "TAKEOVER" HADR COMMAND SOMETIMES CAUSES "LOG CHAIN MISMATCH" ERROR, LEADING TO FAILURE OF STANDBY IN HADR SETUP.

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • It has been observed that when a particular sequence of steps
    are executed, HADR standby fails to come up.
    The reproduction steps are :
    
    a) Issue "db2 takeover hadr on db <dbname>" from standby
    b) Issue "db2_kill" from new primary
    c) After 1 minute , issue "db2 takeover hadr on db <dbname> by
    force peer window only" from standby
    d) After 1 minute, issue "db2start" followed by "db2 start hadr
    on db <dbname> as standby"
    
    The db2diag.log shows the following error messages :
    
    2013-01-11-15.59.05.509769+240 I38363E380          LEVEL:
    Warning
    PID     : 5226                 TID  : 47972704315712PROC :
    db2sysc
    INSTANCE: inst1            NODE : 000          DB   : ABC
    EDUID   : 47                   EDUNAME: db2hadrp (ABC)
    FUNCTION: DB2 UDB, recovery manager, sqlpLogChainMatch, probe:20
    MESSAGE : Log chain mismatch detected: 11 0,1476536718
    
    2013-01-11-15.59.05.509837+240 E38744E686          LEVEL: Error
    PID     : 5226                 TID  : 47972704315712PROC :
    db2sysc
    INSTANCE: inst1             NODE : 000          DB   : ABC
    EDUID   : 47                   EDUNAME: db2hadrp (ABC)
    FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
    probe:20500
    MESSAGE : ADM12500E  The HADR standby database cannot be made
    consistent with the primary database.
    The log stream of the standby database is incompatible with that
    of the primary database.
    To use this database as a standby, it must be recreated from a
    backup image or split  mirror of the primary database.
    
    The likely root cause is a special boundary condition where the
    forced takeover was executed on a standby that was from a
    consistent point without replaying any log records.
    

Local fix

  • As a temporary workaround:
    1. Take a full backup on Primary
    2. Restore it on Standby
    3. Re-initiliaze Hadr by starting db as standby
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * Customers using HADR feature of DB2                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to DB2 V97fp9 fixpack.                               *
    ****************************************************************
    

Problem conclusion

  • The fix will be included in DB2 v97fp9
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC90020

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    970

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-02-04

  • Closed date

    2014-01-06

  • Last modified date

    2015-11-10

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • R970 PSN

       UP

  • R970 PSY

       UP



Document information

More support for: DB2 for Linux, UNIX and Windows

Software version: 9.7

Reference #: IC90020

Modified date: 10 November 2015