DB2 FOR LUW / DB2FORLUW / A50 - DB2

Due to a logic error on pureScale systems, the locklist manager 
might calculate an unexpectedly low internal "maximum locks per 
transaction" value.  This results in lock escalations when 
applications are holding a small number of locks and a locklist 
that is not exhausted.  The calculation error is due to an 
incorrectly maintained internal counter which tends to increase 
over time, so the issue is more likely seen the longer a 
database is active. 
 
Systems where STMM is tuning locklist (and maxlocks) are highly 
vulnerable since the "maximum locks per transaction" is 
recalculated after database activation.  However, the problem 
might also be introduced on a system if locklists or maxlocks 
are updated dynamically, since the "maximum locks per 
transaction" are recalculated at that time and might be 
influenced by the invalid internal counter. 
 
The example escalation below shows a lock escalation that is 
occurring even though the application is holding only 33 locks. 
It is reported that this is due to reason code 1, which means 
that the maximum allowed locks for the application has been 
reached.  This is virtually impossible because of the low 
locklist and maxlocks settings, and implies the system is 
encountering the incorrect locklist manager calculation: 
 
FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:1 
MESSAGE : ADM5501I  DB2 is performing lock escalation. The 
        affected application is named "db2bp", and is associated 
        with the workload name "SYSDEFAULTUSERWORKLOAD" and 
        application ID "*N0.mcornish.131114133735" at member 
        "0". The total number of locks currently held is "33", 
        and the target number of locks to hold is "16". The 
        current statement being executed is "drop table t1". 
        Reason code: "1"

**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 LUW pureScale systems                                    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Update to 10.5.0.3                                           * 
****************************************************************

Use manual locklist tuning as opposed to STMM, and avoid 
dynamically altering the locklist or maxlocks settings.  On a 
system experiencing unexpected locklist escalations, recycling 
the database will reset the internal "maximum locks per 
transaction" parameter to a normal value.

DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 3a for Linux, UNIX, and Windows
 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
 

Problem Fixed In 10.5.0.3

see Local Fix

forerunner  : APAR is sysrouted TO one or more of the following: IC97896 IC97897 
follow-up : 

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

20.11.2013
28.02.2014
02.07.2014