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 |