This APAR applies to STMM configurations where DATABASE_MEMORY
is a fixed value or AUTOMATIC.
If there is a tuning increase failure, STMM may incorrectly try
to compensate for the failure by repeatedly trying to include
the amount of the failure in future tuning increases. These
future increases may be over-aggressive and be aborted to avoid
overcommiting memory on a system, resulting in further tuning
increase failures.
The failures themselves have no impact on the system, the check
occurs before any configuration change is attempted.
The impact can be that STMM stops performing more reasonable
tuning increases, i.e. optimal performance may not be obtained.
The first event seen is an initial tuning increase failure,
which can be normal, and is logged to both the STMM log and the
db2diag.log:
FUNCTION: DB2 UDB, Self tuning memory manager,
stmmCheckIfFreeMemoryIsEnoughForSizeIncr, probe:667
MESSAGE : ZRC=0xFFFFEC49=-5047
DATA #1 : String, 146 bytes
There is not enough free memory for size increase.
Secondly, the STMM logs will show a non-0 value for lost4KPages:
Interval = 7986, State = 0, intervalsBeforeStateChange = 0,
lost4KPages = 825056
Thirdly, additional tuning increase failures will occur.
This condition may persist for long periods of time, until other
STMM tuning activity brings the lost4KPages value back down to
0.
The lost4KPages value should always be 0 except when
DATABASE_MEMORY = COMPUTED, and this will be addressed in this
APAR. |
****************************************************************
* USERS AFFECTED: *
* Systems configured to use self-tuning Database Memory *
* (SELF_TUNING_MEM=ON, DATABASE_MEMORY=AUTOMATIC) *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* If lost4KPages is non-0 for long periods of time, upgrade to *
* DB2 9.7 Fix Pack 4
*
**************************************************************** |
