When an STMM configuration update fails in DPF - other than a
bufferpool change - it may leave the configuration in an
inconsistent state across the partitions being tuned. For
example, an update to SHEAPTHRES_SHR, PCKCACHESZ, or LOCKLIST
may be successful on some partitions and be rolled back on
others. This can cause problems with subsequent STMM tuning
since the planning of tuning changes assumes all tuned
partitions are similar to the tuning partition. For example,
subsequent STMM tuning changes may consistently fail, preventing
STMM from adjusting to workload demands.
There are many db2diag.log entries when an STMM tuning failure
occurs in DPF, but the specific entry to look for is the
following, with an incorrect listing of "nodes that failed"
(these are the nodes where the tuning change actually succeeds):
2011-07-07-01.07.40.143255+120 I5749387A914 LEVEL: Error
PID : 5763200 TID : 3343 PROC : db2sysc
2
INSTANCE: udb500 NODE : 002 DB : SAMPLE
APPHDL : 2-51 APPID: *N2.DB2.110706225945
AUTHID : db2inst1
EDUID : 3343 EDUNAME: db2stmm (SAMPLE) 2
FUNCTION: DB2 UDB, config/install, sqlfPdbUpdDbCfgReq,
probe:1260
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : sqlcabc: 0 sqlcode: -5124 sqlerrml: 1
sqlerrmc: 1
sqlerrp :
sqlerrd : (1) 0x00000000 (2) 0x00000000 (3)
0x00000000
(4) 0x00000000 (5) 0x00000000 (6)
0x00000001
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:
DATA #2 : String, 73 bytes
Number of failed nodes: 10
Nodes that failed: 3, 4, 5, 6, 7, and others.
The configuration on the tuned partitions can also be checked to
see whether the PCKCACHESZ, LOCKLIST, and SHEAPTHRES_SHR
settings are consistent. |
