DB2 FOR LUW / DB2FORLUW / A10 - DB2

DB2 may panic in sqldInvCursorPos() function on non-coordinator 
partitions during a commit of a transaction in a DPF environment 
involving a global variable in which the default value includes 
a select from a table 
( Example: db2 create variable m.max_hit int DEFAULT  ((select 
max(c1) from m.t1)) ; db2 set m.max_hit int = DEFAULT ). 
You will see the following in the db2diag.log when the failure 
starts: 
 
2011-12-28-03.23.55.319028-480 I1556195E464        LEVEL: Severe 
PID     : 16826                TID  : 46931006974272PROC : 
db2sysc 69 
INSTANCE: db2inst1             NODE : 069          DB   : SAMPLE 
APPHDL  : 0-25295              APPID: 
10.184.144.110.9988.11122810421 
AUTHID  : db2inst1 
EDUID   : 215248               EDUNAME: db2agnta (SAMPLE) 69 
FUNCTION: DB2 UDB, data management, sqldInvCursorPos, probe:3585 
MESSAGE : Unheld scan is open during COMMIT. 
 
2011-12-28-03.23.55.331379-480 I1556660E544        LEVEL: Severe 
PID     : 16826                TID  : 46931006974272PROC : 
db2sysc 69 
INSTANCE: db2inst1             NODE : 069          DB   : SAMPLE 
APPHDL  : 0-25295              APPID: 
10.184.144.110.9988.11122810421 
AUTHID  : db2inst1 
EDUID   : 215248               EDUNAME: db2agnta (SAMPLE) 69 
FUNCTION: DB2 UDB, trace services, sqlt_logerr_string (secondary 
logging fu, probe:0 
MESSAGE : SQLD_CCB: 
DATA #1 : String, 57 bytes 
pool(TID)=65530, obj(FID)=32795, indexid(IID)=1, class=48 
 
2011-12-28-03.23.55.331540-480 I1557205E178       LEVEL: Severe 
PID:16826 TID:46931006974272 NODE:069 Title: SQLD_CCB 
Dump File:/db2fs/db2inst1/db2dump/16826.215248.069.dump.bin

**************************************************************** 
* USERS AFFECTED:                                              * 
* All users                                                    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 10.1 Fixpack 1 or later               * 
****************************************************************

Possible workarounds: 
 
a) Avoid interrupting the statement that first references the 
variable. 
 
b) When a statement referencing the global variable is 
interrupted, explicitly rollback the transaction. 
 
c) Do not create the variable with a default expression. 
Instead, before referencing the variable the first time (or 
perhaps right after a connect), one could explicitly set the 
variable to the desired expression, and effectively get the same 
'default behaviour'

DB2 Version 10.1 Fix Pack 1 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 2 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

Problem first fixed in DB2 Version 10.1 Fixpack 1

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

13.06.2012
06.11.2012
06.11.2012