home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
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
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC93299 Status: Geschlossen

STMM UNNECESSARILY DECREASES CONFIGURATION WHEN 0 BENEFIT DETECTED

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
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.
Problem-Zusammenfassung:
**************************************************************** 
* 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                        * 
****************************************************************
Local-Fix:
use a fixed database_memory setting
verfügbare FixPacks:
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

Lösung
Problem first fixed in DB2 Version 9.7 Fix pack 9
Workaround
See Local Fix
Bug-Verfolgung
Vorgänger  : APAR is sysrouted TO one or more of the following: IC93472 IC93475 IC95488 
Nachfolger : 
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
21.06.2013
26.12.2013
26.12.2013
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP9
Problem behoben lt. FixList in der Version
9.7.0.9 FixList
9.7.0.9 FixList