home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IT02311 Status: Closed

PANIC IN SQLO_XLATCH::RELEASE CONFLICT WHEN UNLOCKING AN UNLATCHED LOCK

product:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problem description:
In a federated server utilizing two-phase-commits and LOCK 
SNAPSHOTS, it is possible for the engine to panic in SQLO_XLATCH 
with a probe(in db2diag.log) indicating release conflict when 
unlocking an unlatched lock. 
 
snippet from db2diag.log: 
<timestamp>                                       LEVEL: Severe 
PID     : <my_pid>             TID  : <my_tid>       PROC : 
db2sysc 
INSTANCE: <my_inst>             NODE : <node>         DB   : 
<db_name> 
APPHDL  : <app_hdl>              APPID: <my_app_id> 
AUTHID  : <auth_id> 
EDUID   : <eduid>                EDUNAME: <edu_name> 
FUNCTION: DB2 UDB, SQO Latch Tracing, 
sqlo_xlatch::releaseConflict, probe:10 
DATA #1 : String, 27 bytes 
unlocking an unlatched lock 
DATA #2 : Pointer, 8 bytes 
0x0700000171b69868 
DATA #3 : String, 123 bytes 
{ 
   lock          = { 0x00000000 [ unlocked ] } 
   identity      = 
SQLQG_F2PC_T::federatedProcessingSnapshotLatch (144) 
} 
DATA #4 : Hexdump, 8 bytes 
0x0700000171B69868 : 0000 0000 0090 0000 
........ 
CALLSTCK: (Static functions may not be resolved correctly, as 
they are resolved to the nearest symbol) 
  [0] 0x090000000D5437D4 pdLog + 0xE0 
  [1] 0x090000000D95E5F0 pdLog@glue413 + 0x12C 
  [2] 0x090000000DB8CB60 sqloSpinLockReleaseConflict + 0x5C 
  [3] 0x090000000D36A248 sqloSpinLockReleaseConflict@glue73 + 
0x78 
  [4] 0x090000000EE8F608 
sqlpm_write_locks_indoubt_tran__FP16sqeLocalDatabaseP8sqeAgentP1 
9sqm_snapshot_bufferUiPUiT5P16sqlm_header_info + 0x64C 
  [5] 0x090000000EE8DD14 
@92@sqm_snap_db_locks__FPC16sqm_agent_entityRC8sqlo_gmtP19sqm_sn 
apshot_bufferP16sqeLocalDatabaseP14sqlm_collectedPCcCUiPP15sqlm 
+ 0x564 
  [6] 0x090000000CD006D0 
sqlmonssagnt__FUi13sqm_entity_idP6sqlmaiT1PvP14sqlm_collectedUsT 
7P5sqlca + 0xD2C 
  [7] 0x090000000D922EBC sqlmonssbackend__FP12SQLE_DB2RA_T + 
0x228 
  [8] 0x090000000DBDD12C sqlesrvr__FP14db2UCinterface + 0x738 
  [9] 0x090000000D351B68 sqleMappingFnServer__FP5sqldaP5sqlca + 
0x1D0 
 
 
 
The stack would look similar to this: 
 
<StackTrace> 
-------Frame------ ------Function + Offset------ 
0x090000000066CF54 pthread_kill + 0xD4 
0x090000000CD0B4E4 sqloDumpEDU + 0x54 
0x090000000CB9B448 sqle_panic__Fv + 0xBC 
0x090000000DF49B50 sqle_panic__Fv@glue198 + 0x7C 
0x090000000DB8CB68 sqloSpinLockReleaseConflict + 0x64 
0x090000000D36A248 sqloSpinLockReleaseConflict@glue73 + 0x78 
0x090000000EE8F608 
sqlpm_write_locks_indoubt_tran__FP16sqeLocalDatabaseP8sqeAgentP1 
9sqm_snapshot_bufferUiPUiT5P16sqlm_header_info + 0x64C 
0x090000000EE8DD14 
@92@sqm_snap_db_locks__FPC16sqm_agent_entityRC8sqlo_gmtP19sqm_sn 
apshot_bufferP16sqeLocalDatabaseP14sqlm_collectedPCcCUiPP15sqlm_ 
dbase_lockP16sqlm_header_info + 0x564 
0x090000000CD006D0 
sqlmonssagnt__FUi13sqm_entity_idP6sqlmaiT1PvP14sqlm_collectedUsT 
7P5sqlca + 0xD2C 
0x090000000D922EBC sqlmonssbackend__FP12SQLE_DB2RA_T + 0x228 
0x090000000DBDD12C sqlesrvr__FP14db2UCinterface + 0x738 
0x090000000D351B68 sqleMappingFnServer__FP5sqldaP5sqlca + 0x1D0 
0x090000000D351470 
sqlerKnownProcedure__FiPcPiP5sqldaT4P13sqlerFmpTableP8sqeAgentP5 
sqlca + 0x344 
0x090000000D3503A8 sqlerCallDL__FP14db2UCinterfaceP9UCstpInfo + 
0x580 
0x090000000D350980 
.sqljs_ddm_excsqlstt.fdpr.clone.253__FP14db2UCinterfaceP13sqljDD 
MObject + 0xE4 
0x090000000D50E55C 
sqljsParseRdbAccessed__FP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UC 
interface + 0x110 
0x090000000D50E204 
.sqljsParse.fdpr.clone.234__FP13sqljsDrdaAsCbP14db2UCinterfaceP8 
sqeAgentb + 0x6D8 
0x090000000D511984 @63@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb 
+ 0x2C0 
0x090000000D667148 
@63@sqljsDriveRequests__FP8sqeAgentP14db2UCconHandle + 0xB4 
0x090000000D666E38 
@63@sqljsDrdaAsInnerDriver__FP18SQLCC_INITSTRUCT_Tb + 0x2D4 
0x090000000D6668BC sqljsDrdaAsDriver__FP18SQLCC_INITSTRUCT_T + 
0xFC 
0x090000000D2E5A3C RunEDU__8sqeAgentFv + 0x280 
0x090000000D2E0EA8 EDUDriver__9sqzEDUObjFv + 0xDC 
0x090000000D30DAEC sqloEDUEntry + 0x254 
</StackTrace>
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All Platforms                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 LUW v10.5 Fixpack 4 or Later.                 * 
****************************************************************
Local Fix:
This panic can be avoided by turning off FEDERATED processing
available fix packs:
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows

Solution
First Fixed in DB2 LUW v10.5 Fixpack 4.
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
06.06.2014
08.09.2014
08.09.2014
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.5.0.4 FixList