DB2 FOR LUW / DB2FORLUW / 950 - DB2

UNDER RARE CONDITIONS, THE QUERY COMPILER FAILS TO HANDLE AN OUT 
OF STMTHEAP CONDITION. 
 
Description: 
Under rare conditions, during query compilation, the query 
compiler fails to handle an out of STMTHEAP condition.  When the 
problem is encountered, you might observe one of the following 
outcomes: 
 
1. A trap in function sqlraFixupSqlDD with a partial stack of: 
 
        sqlraFixupSqlDD 
        sqlra_fill_var 
        sqlra_compile_var 
        sqlra_find_var 
        sqlra_get_var 
        sqlrr_prepare 
 
2. An error sqlcode -901 where the SQLCA's sqlerrmc field has 
token "unexpected NULL ZValue". 
 
3. A memory error such as sqlcode -101 or sqlcode -83, where the 
SQLCA's sqlerrp field is SQLNO002.  In this situation, the 
statement might reside in the package cache causing a subsequent 
attempt to compile the same statement to return the same error 
until the statement is evicted from the cache.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All users, but rarely                                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* UNDER RARE CONDITIONS, THE QUERY COMPILER FAILS TO HANDLE    * 
* ANOUT OF STMTHEAP CONDITION.Description:Under rare           * 
* conditions, during query compilation, the querycompiler      * 
* fails to handle an out of STMTHEAP condition.  Whenthe       * 
* problem is encountered, you might observe one of             * 
* thefollowing outcomes:1. A trap in function sqlraFixupSqlDD  * 
* with a partial                                               * 
* stackof:sqlraFixupSqlDDsqlra_fill_varsqlra_compile_varsqlra_fi 
* An error sqlcode -901 where the SQLCA's sqlerrmc fieldhas    * 
* token "unexpected NULL ZValue".3. A memory error such as     * 
* sqlcode -101 or sqlcode -83, wherethe SQLCA's sqlerrp field  * 
* is SQLNO002.  In this situation,the statement might reside   * 
* in the package cache causing asubsequent attempt to compile  * 
* the same statement to returnthe same error until the         * 
* statement is evicted from thecache.                          * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Version 9.5 Fix Pack 6 or later releasecontaining * 
* the fix.                                                     * 
****************************************************************

The likelihood of experiencing this problem is increased if the 
STMTHEAP database configuration parameter is set to AUTOMATIC (a 
feature available in DB2 starting with V9.5).  If this is the 
case, modify STMTHEAP to a manual value without the AUTOMATIC 
attribute. 
 
For example, if 
 
 
GET DATABASE CONFIGURATION [FOR database-alias] SHOW DETAIL 
 
 
 shows: 
 
 
 Description                Parameter     Current Value 
Delayed Value 
 --------------------------------------------------------------- 
------------ 
 SQL statement heap (4KB)   (STMTHEAP)  = AUTOMATIC(4267) 
AUTOMATIC(12000) 
 
 
you can modify STMTHEAP to the delayed on-disk value of 12000 
with: 
 
 
UPDATE DATABASE CONFIGURATION [FOR database-alias] USING 
STMTHEAP 12000 
 
 
Connect to the database prior to the UPDATE action so that the 
change will be dynamic versus deferred.  After the UPDATE 
action, verify the current value to confirm the change took 
effect. 
 
Specific to outcome 3 above, you can evict the statement from 
the package cache by doing a RUNSTATS operation against a table 
involved in the SQL statement or by running the FLUSH PACKAGE 
CACHE statement.  The former will evict from the package cache 
all statements that are dependent on the table against which the 
RUNSTATS is being issued.  The latter will effectively evict all 
dynamic SQL from the package cache.  Depending on the workload, 
evicting statements other than the problematic one might result 
in a performance degradation until the cache is repopulated.

DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
 

Problem was first fixed in Version 9.5 Fix Pack 6.

See Local Fix.

forerunner  : APAR is sysrouted TO one or more of the following: IC65594 IC65598 
follow-up : 

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

13.01.2010
14.06.2010
14.06.2010

9.5.FP6