Since 9.5 GA, STMM has been using database memory statistics
from before the tuning cycle to adjust database memory overflow,
if needed, at the end of the cycle. This is incorrect, as
Database Memory may have changed significantly during the cycle,
including from STMM tuning itself. This occasionally results in
internal failures logged to the db2diag.log. This is corrected
in the next tuning cycle, and has no significant effect on
database operations or STMM tuning.
Sample db2diag.log messages:
2010-08-04-17.39.26.305875+120 E14014A730 LEVEL: Warning
PID : 503850 TID : 20304 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-54 APPID: *N0.DB2.100729183327
AUTHID : db2inst1
EDUID : 20304 EDUNAME: db2stmm (SAMPLE) 0
FUNCTION: DB2 UDB, Self tuning memory manager,
stmmDecreaseDBMemOriginatedBySTMM, probe:1616
MESSAGE :
ZRC=0x02AE00A5=44957861=STMM_DBMEM_COULD_NOT_BE_DECREASED
"The DATABASE_MEMORY parameter could not be decreased"
DATA #1 : String, 141 bytes
Overflow memory decrease amount exceeds overflow size.
DATABASE_MEMORY decrease failed. Decrease amount: 686325760,
overflow size: 634912768
2010-08-04-17.39.26.313915+120 I14745A564 LEVEL: Severe
PID : 503850 TID : 20304 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-54 APPID: *N0.DB2.100729183327
AUTHID : db2inst1
EDUID : 20304 EDUNAME: db2stmm (SAMPLE) 0
FUNCTION: DB2 UDB, config/install, sqlfUpdateDbCfg, probe:5417
MESSAGE : ZRC=0x00000553=1363
DATA #1 : <preformatted>
DB cfg update happened non-dyn resulting in 1363.
action: 5 |
