IBM Support

IT35573: HADR TAKEOVER FAILED WHEN DECLARE GLOBAL TEMPORARY TABLE IS USED IN DISTRIBUTED TRANSACTION

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • When DECLARE GLOBAL TEMPORARY TABLE is used by a distributed
    transaction on the HADR primary, there is a small timing window
    that
    can cause HADR TAKEOVER to fail.
    
    The following messages can be found in the db2diag.log of the
    HADR
    primary:
    
    
    2020-11-03-23.15.19.148631+000 I1213679E1966         LEVEL:
    Severe
    PID     : 8446                 TID : 140733461817088 PROC :
    db2sysc 0
    INSTANCE: db2i1                NODE : 000            DB   : MYDB
    APPHDL  : 0-27695              APPID: *LOCAL.DB2.201103231944
    HOSTNAME: host1.myco.com
    EDUID   : 883                  EDUNAME: db2agent (MYDB) 0
    FUNCTION: DB2 UDB, data management, sqldFixExistingTCB,
    probe:12675
    MESSAGE : ZRC=0x82040001=-2113667071=SQLD_NONSEVERE_PRGERR
              "non-severe dms programming error"
              DIA8532C An internal processing error has occurred.
    DATA #1 : String, 17 bytes
    Expected TEMP TCB
    DATA #2 : String, 7 bytes
    sqldtcb
    CALLSTCK: (Static functions may not be resolved correctly, as
    they are resolved to the nearest symbol)
      [0] 0x00007FFFF356A65D sqlzSetAndLog901 + 0x29D
      [1] 0x00007FFFEDAB2E7F
    _Z18sqldFixExistingTCBP16sqeLocalDatabaseP9SQLP_LSN8iiiiPP8SQLD_
    TCB + 0x48F
      [2] 0x00007FFFEDA784DF
    _Z10sqldomUndoP8sqeAgentP10SQLDOM_LRHP9SQLP_LSN8sP15SQLD_RECOV_I
    NFO + 0x6EF
      [3] 0x00007FFFEDA71596
    _Z8sqldmundP8sqeAgentP8SQLP_LRHPcP15SQLD_RECOV_INFO + 0x626
      [4] 0x00007FFFF0824368
    _Z8sqlptudoP8sqeAgent12sqlpUndoTypePmP15SQLD_RECOV_INFOP11SQLP_T
    ENTRYP8SQLP_LRHPc + 0x1D8
      [5] 0x00007FFFF082366B _Z8sqlptud1P8sqeAgentm + 0x27B
      [6] 0x00007FFFF0813531
    _Z8sqlpxrbkP8sqeAgentP15SQLXA_CALL_INFOP9SQLP_GXIDPP11sqlo_xlatc
    h + 0x401
      [7] 0x00007FFFF28F71F0
    _Z36sqlpHadrRollbackTransDuringPTakeoverP8sqeAgent + 0xE0
      [8] 0x00007FFFF28F7AE4
    _Z31sqlpHadrPreparePrimaryToStandbyP8sqeAgentPm + 0x54
      [9] 0x00007FFFF121A2A8 _Z24hdrCleanupXATransactionsP8sqeAgent
    + 0xB8
      [10] 0x00007FFFEF7FC6CA
    _Z26sqleIndCoordProcessRequestP8sqeAgent + 0x13DA
      [11] 0x00007FFFEF80B5E9 _ZN8sqeAgent6RunEDUEv + 0x499
      [12] 0x00007FFFF1025227 _ZN9sqzEDUObj9EDUDriverEv + 0xF7
      [13] 0x00007FFFF07DD8C3 sqloEDUEntry + 0x303
    
    ...
    
    2020-11-03-23.15.34.621841+000 I1578053E531          LEVEL:
    Error
    PID     : 8446                 TID : 140733461817088 PROC :
    db2sysc 0
    INSTANCE: db2i1                NODE : 000            DB   : MYDB
    APPHDL  : 0-27695              APPID: *LOCAL.DB2.201103231944
    HOSTNAME: host1.myco.com
    EDUID   : 883                  EDUNAME: db2agent (MYDB) 0
    FUNCTION: DB2 UDB, High Availability Disaster Recovery,
    hdrCleanupXATransactions, probe:46000
    MESSAGE : Error in takeover XA cleanup icoord: zrc = 0x87040055
    
    
    The problem is uncommon.  It only occurs when TAKEOVER is
    executing at the time such distributed transaction has just
    completed xa_end processing before starting xa_prepare
    processing.
    

Local fix

  • Reissuing the TAKEOVER command will likely be successful.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * AIX/LINUX                                                    *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to DB2 v11.1.4.7                                     *
    ****************************************************************
    

Problem conclusion

  • In XA mode we need to ensure that DMS doesn't process DGTT log
    records since they have already been dropped
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT35573

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    B10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-01-18

  • Closed date

    2022-04-17

  • Last modified date

    2022-04-17

  • 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

  • RB10 PSY

       UP

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.1","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
04 May 2022