Under rare timing conditions, with high concurrency, queries
might get stuck in UOW-Executing state with the following
function on the top of the stack of the coordinator agent
(db2agent EDU)
SQLO_SLATCH_CAS64::getConflict
sqlbFindPageInBPOrSim
sqlbfix
At the same time, multiple prefetcehrs (db2pfchr EDUs) will be
show waiting in:
SQLO_SLATCH_CAS64::getConflict
sqlbFindPageInBPForPrefetch
sqlbGetBuffer
sqlbProcessRange
sqlbPFPrefetcherEntryPoint
and one db2agent with sqlbRemovePageFromSimulationArea function
on the stack:
SQLO_SLATCH_CAS64::getConflict
sqlbRemovePageFromSimulationArea
sqlbFindPageInBPOrSim
sqlbfix
db2pd -latches will report multiple waiters on the same
SQLO_LT_SQLB_HASH_BUCKET_GROUP_HEADER__groupLatch address, with
the latch holder EDU ID changing across iterations.
MON_GET_LATCH query, e.g.:
select substr(latch_name,1,40) latch_name,
substr(memory_address,1,20) memory_address,
edu_id,
substr(edu_name,1,20) edu_name,
application_handle,
member,
latch_status,
latch_wait_time
from table ( mon_get_latch( null, -2 ) ) where latch_status =
'W' order by latch_wait_time
might show at least one EDU_ID waiting on that latch address for
significant amount of time.
Problem is specific to databases where size of bufferpool(s) is
controlled by STMM (SIZE AUTOMATIC) and it is more likely to be
exposed on systems with large number of CPUs, very large
bufferpool and under a heavy prefetch activity. |
