An agent calling FLUSH OPTIMIZATION PROFILE CACHE and an agent
using an OPT profile can get into a "deadlock" of sorts with one
agent waiting on a latch while the other is waiting on a lock.
This looks very similar to APAR IZ26477, but is the result of
the FLUSH OPTIMIZATION PROFILE CACHE instead of an Online Reorg.
In the latch tracking part of the stack files you will see:
<<<< File = <thread_1> >>>>
timestamp: 2009-09-16-14.56.27.914060
Holding Latch type: (SQLO_LT_sqlrlc_anchor_common__anchor_latch)
- Address: (256
cd9b4c), Line: 71, File:
/view/db2_v91fp3a_sun64_s070914/vbs/engn/include/sqlrlc
_inlines.h
Holding Latch type: (SQLO_LT_sqlrlc_anchor_common__lru_latch) -
Address: (256cd9
b50), Line: 239, File: sqlrlc_flush.C
<<<< File = <thread_2> >>>>
timestamp: 2009-09-16-14.51.15.944435
Waiting on latch type:
(SQLO_LT_sqlrlc_anchor_common__anchor_latch) - Address: (
256cd9b4c), Line: 1042, File: sqlrlc_request_usage.C
timestamp: 2009-09-16-14.56.23.561822
Waiting on latch type:
(SQLO_LT_sqlrlc_anchor_common__anchor_latch) - Address: (
256cd9b4c), Line: 1042, File: sqlrlc_request_usage.C
and the db2pd output will show:
Applications:
Address AppHandl [nod-index] NumAgents CoorPid
Status C-AnchID C-StmtUID L-AnchID L-StmtUID
Appid
0x00000002006FB860 236 [000-00236] 1 <thread_1>
Lock-wait 155 1 228 1
*LOCAL.db2inst1.090916045036
0x00000002005DF800 192 [000-00192] 1 <thread_2>
UOW-Executing 0 0 6 1
*LOCAL.db2inst1.090916044452
So, thread_1 is holding a latch thread_2 needs and thread_2
needs the lock that thread_1 is holding. |
