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 IC65594 Status: Closed

UNDER RARE CONDITIONS, THE QUERY COMPILER FAILS TO HANDLE AN OUT OF
STMTHEAP CONDITION.

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem 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.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All users, but rarely                                        * 
**************************************************************** 
* PROBLEM 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.7 Fix Pack 2 or later releasecontaining * 
* the fix.                                                     * 
****************************************************************
Local 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.
available fix packs:
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Solution
Problem was first fixed in Version 9.7 Fix Pack 2.
Workaround
See Local Fix.
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
15.01.2010
25.05.2010
25.05.2010
Problem solved at the following versions (IBM BugInfos)
9.7.FP2
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.2 FixList