IC95911: IN AN AUTOMATED HADR ENVIRONMENT THE TAKEOVER HADR COMMAND SUCCEEDS, BUT A MOVE REQUEST IS NOT SENT TO TSA

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • In an automated HADR environment, the "db2 takeover hadr on db
    <dbname>" may succeed without a corresponding move request being
    processed by TSA. Here are the log messages seen in the TSA
    RecoveryRM trace summary file in the case of a successful
    user-initiated HADR takeover:
    
    07/31/13 11:02:02.194944 T(3600) _RCD LockResource request
    injected:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:05.430001 T(3600) _RCD UnlockResource Request
    removed:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:07.716282 T(3600) _RCD LockResource request
    injected:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:08.751917 T(782) _RCD LockTrees Request injected:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:08.784144 T(782) _RCD UnlockResource Request
    removed:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:10.066568 T(3600) _RCD Move Request injected:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:10.145023 T(3600) _RCD LockResource request
    injected:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:10.284629 T(3600) _RCD LockTrees Request
    injected:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:02:11.428430 T(782) _RCD UnlockResource Request
    removed:
    db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
    
    The log message which corresponds to the move request is the one
    which contains this string:"Move Request injected".
    
    Here is how the TSA log messages look like in the failure case:
    
    07/31/13 11:09:48.563402 T(3600) _RCD LockResource request
    injected:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:09:51.421614 T(3600) _RCD UnlockResource Request
    removed:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:09:53.464228 T(3600) _RCD LockResource request
    injected:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:09:54.490655 T(782) _RCD LockTrees Request injected:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:09:54.822743 T(3600) _RCD UnlockResource Request
    removed:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
      (we expect to see a log corresponding to the move request
    here)
    07/31/13 11:09:55.331735 T(3600) _RCD LockResource request
    injected:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:10:26.472014 T(782) _RCD LockTrees Request injected:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    07/31/13 11:10:26.501101 T(782) _RCD UnlockResource Request
    removed:
    db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
    
    In this case, the move request was not processed by TSA and as a
    result DB2 and TSA are out of sync. If the primary HADR database
    resides on hostA and the standby resides on hostB, TSA will
    believe the primary resides on hostB and that the standby
    resides on hostA. The result is a database outage.
    
    The cause of this issue is a TSA bug which has been fixed in TSA
    v3.2.2. This problem is only reproducible on versions of TSA
    lower than v3.2.2.
    

Local fix

  • Upgrade to TSA v3.2.2.x or higher.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * All                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to DB2 v9.7 FP9.                                     *
    ****************************************************************
    

Problem conclusion

  • Fixed in DB2 v9.7 FP9.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC95911

  • 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-09-12

  • Closed date

    2014-01-06

  • Last modified date

    2014-01-06

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

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

    IC96209 IC96210

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • R980 PSN

       UP

  • RA10 PSN

       UP

  • RA50 PSN

       UP



Rate this page:

(0 users)Average rating

Document information


More support for:

DB2 for Linux, UNIX and Windows

Software version:

9.7

Reference #:

IC95911

Modified date:

2014-01-06

Translate my page

Machine Translation

Content navigation