DB2 - Problem description
| Problem IC79182 | Status: Closed |
PERFORMANCE SLOWDOWN DURING BUFFER POOL FLUSH WHEN STMM IS ALTERING THE BUFFER POOL, ONLINE BACKUP RUNNING, | |
| product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
| Problem description: | |
This is an infrequent timing issue that can only happen if the
following conditions are true:
1) STMM altering a buffer pool
2) Online database backup has started. As the result of this,
dirty pages from the same buffer pool are being written out to
the disk (the buffer pool is being flushed)
3) Page cleaners are paused by STMM
An optional condition making the problem worse is:
4) The TRACKMOD DB CFG configuration parameter is enabled
Under these conditions, the buffer pool flush may take a long
time (even hours or longer, depending on the number of dirty
pages that need to be written out), which the end user may
perceive as a hang. The user will not be force off the running
backup during this time. The following symptoms will be seen:
ad 1) STMM altering a buffer pool:
EDU "db2stmm" waiting for the
"SQLO_LT_SQLB_BufferPool__prevBPDCachingLatch" latch. The call
stack for this EDU will have the "sqlbFinalizeRTBPState" eye
catcher present on the stack, usually similar to:
getConflictComplex
getConflict
sqlbFinalizeRTBPState
sqlbAlterBufferPoolAct
sqlbAlterAutomaticBufferPool
sqlrlStmmAlterBufferPool
stmmAlterBufferPool
ad 2) Online backup flushing the same buffer pool:
The owner of "SQLO_LT_SQLB_BufferPool__prevBPDCachingLatch" will
be "db2bm". This EDU will be flushing the buffer pool. Call
stacks taken in several iterations will reveal this EDU in
various phases of writing out dirty pages, typically during file
system write operations. If TRACKMOD enabled, the flush will
take even longer because we will need to write more dirty pages
than with TRACKMOD disabled. An example call stack will contain
"sqlbFlushFull":
pwrite64
sqloseekwrite64
sqloWriteBlocks
sqlbWriteBlocks
sqlbWritePageToDisk
sqlbWritePage
sqlbFlushForDLSubset
sqlbFlush
sqlbFlushFull
sqlubBMCont
sqlubbuf
ad 3) Page cleaners paused
All the page cleaners ("db2pclnr" EDUs) will be paused. Their
call stack will show "sqlbClnrCheckAndPause", for example:
semtimedop
sqloWaitEDUWaitPost
sqlbClnrCheckAndPause
sqlbClnrFindWork
sqlbClnrEntryPoint
sqbPgClnrEdu | |
| Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * Users using the DB2 version prior to V9.7 Fixpack 6 * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 V9.7 Fixpack 6 * **************************************************************** | |
| Local Fix: | |
1) Alter the buffer pool, making it non-automatic (manual), i.e. not tunable by STMM, OR 2) Take an offline backup if possible | |
| available fix packs: | |
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows | |
| Solution | |
First Fixed in DB2 V9.7 Fixpack 6 | |
| Workaround | |
not known / see Local fix | |
| BUG-Tracking | |
forerunner : APAR is sysrouted TO one or more of the following: IC84141 follow-up : | |
| Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 12.10.2011 12.06.2012 19.07.2012 |
| Problem solved at the following versions (IBM BugInfos) | |
9.7.FP6 | |
| Problem solved according to the fixlist(s) of the following version(s) | |
| 9.7.0.6 |
|