DB2 FOR LUW / DB2FORLUW / 970 - DB2

If the STMM tuner detects a "0" benefit/cost for all STMM-tuned 
areas, and only a single database is being tuned, the free 
memory target will switch from the minimum to the maximum value 
in the free memory target range.  (eg. from 1% to 10% of RAM). 
This may trigger a corresponding decrease in the STMM-tuned 
configuration (eg. large decrease in bufferpools).  The 
assumption is that the database is idle, but often this is a 
very temporary condition, or is a result of limiting STMM tuning 
to areas which often don't have a continuous high need for 
memory (eg. locklist, package cache).  The magnitude of the 
switch is large and can disrupt performance.  Instead, the 
minimum free target should be maintained (the STMM tuner will 
still react to constrained memory conditions as part of normal 
tuning). 
 
Note this issue applies only when database_memory is automatic 
and stmm tuning is enabled. 
 
The STMM logs will contain an entry similar to the following : 
FUNCTION: DB2 UDB, Self tuning memory manager, 
stmmGetDBMemDataAutomatic, probe:3867 
DATA #1 : String, 409 bytes 
Configured memory on the system: 83886080 
Memory currently available on the system: 9763323 
Configured memory on the partition: 67108864 
Memory currently available on the partition: 765120 
Set's configured size: 64637056 
Overflow left: 4693216 
Uncommited size: 3777200 
Target consumer size: 55963646 
Current consumer size: 59943840 
Max growth: 0 
Average benefit: 0 
Partition benefit: DB: SAMPLE      Benefit: 0 
or 
Global benefit: DB: SAMPLE      Benefit: 0 
 
In this case, the Average benefit is 0 for the Sample database. 
It is also the only database competing for memory, so is also 
the highest benefit database - showing up in the line with 
Partition or Global benefit.  The target memory consumption will 
be much lower as compared with normal STMM tuning when this 
condition is detected.

**************************************************************** 
* USERS AFFECTED:                                              * 
* Systems using self-tuning (STMM) of database_memory          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 Fix pack 9                        * 
****************************************************************

use a fixed database_memory setting

DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
 

Problem first fixed in DB2 Version 9.7 Fix pack 9

See Local Fix

forerunner  : APAR is sysrouted TO one or more of the following: IC93472 IC93475 IC95488 
follow-up : 

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

21.06.2013
26.12.2013
26.12.2013

9.7.FP9