|
Problem IT35576
|
Status: Closed |
HADR TAKEOVER FAILED WHEN DECLARE GLOBAL TEMPORARY TABLE IS USED IN A DISTRIBUTED TRANSACTION
|
| product: |
DB2 FOR LUW / DB2FORLUW / B50 - DB2 |
| Problem 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. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* AIX/Linux *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 11.5 m6fp0 *
**************************************************************** |
| Local Fix: |
Reissuing the TAKEOVER command will likely be successful. |
| Solution |
|
| Workaround |
****************************************************************
* USERS AFFECTED: *
* AIX/Linux *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 11.5 m6fp0 *
**************************************************************** |
| Comment |
In XA mode we need to ensure that DMS doesn't process DGTT log
records since they have already been dropped |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 19.01.2021
10.06.2021
10.06.2021 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
