|
Problem IC84361
|
Status: Closed |
PANIC IN SQLDINVCURSORPOS() FUNCTION DURING A COMMIT OF A TRANSACTION INVOLVING A GLOBAL VARIABLE IN DPF |
| product: |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 |
| Problem description: |
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 |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All users *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 Version 10.1 Fixpack 1 or later *
**************************************************************** |
| Local Fix: |
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' |
| available fix packs: |
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
|
| Solution |
Problem first fixed in DB2 Version 10.1 Fixpack 1 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 13.06.2012
06.11.2012
06.11.2012 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.1.0.1
|
 |
| 10.5.0.1
|
|
