From Application Snapshot:
Application handle = 131133
Client login ID = db2inst1
Configuration NNAME of client = prddw3
Process ID of client application = 13320
Coordinator agent process or thread ID = 25
Most recent operation = Execute Immediate
Dynamic SQL statement text:
ALTER TABLESPACE TEMPSPACE2 SWITCH ONLINE
Subsection status = Executing
Execution elapsed time (seconds) = 43909
Agent process/thread ID = 233
From Stack:
======================
?
0x00002AAAAC553BC7
_Z30sqlbTrackMultipleModificationsP20SQLB_DIRECT_WRITE_CB +
0x00ab
0x00002AAAAB8A7020
_Z35sqlbCheckTrackMultipleModificationsP20SQLB_DIRECT_WRITE_CB +
0x0058
0x00002AAAAC579D6E
_Z18sqlbDMSDirectWriteP20SQLB_DIRECT_WRITE_CB + 0x01d8
0x00002AAAAB8BE28C
_Z18sqlbInitPoolHeaderP12SQLB_GLOBALSP12SQLB_POOL_CB + 0x0160
0x00002AAAAC58C232
_Z15sqlbDMSInitPoolP12SQLB_GLOBALSP12SQLB_POOL_CB + 0x01fc
0x00002AAAAB8BDBCA
_Z16sqlbDMSStartPoolP12SQLB_GLOBALSP12SQLB_POOL_CB + 0x05ea
0x00002AAAAC574580
_Z26sqlbSwitchTablespaceOnlinetP12SQLB_GLOBALS + 0x00aa
?
Summary:
Found in 6 stacks of a total of 743 stacks in 251 files
Found in:
./13999.233.002.stack.txt -- db2agntp(TIS_STGP) --
2015-03-04-10.55.17.599303(Signal #10)
./13999.233.002.stack.txt -- db2agntp(TIS_STGP) --
2015-03-04-10.57.18.680600(Signal #10)
./13999.233.002.stack.txt -- db2agntp(TIS_STGP) --
2015-03-04-11.01.43.761363(Signal #12)
Latch:
<LatchInformation>
Waiting on latch type: (SQLO_LT_SQLB_POOL_CB__readLatch) -
Address: (0x2aab833ccc90), Line: 4032, File: sqlbpacc.C
Holding Latch type: (SQLO_LT_SQLB_POOL_CB__readLatch) - Address:
(0x2aab833ccc90), Line: 2139, File:
/view/db2_v97fp9_linuxamd64_s131204/vbs/engn/include/sqlbistorag
e_inlines.h HoldCount: 1
Holding Latch type: (SQLO_LT_SQLB_POOL_CB__writeLatch) -
Address: (0x2aab833ccca0), Line: 2158, File:
/view/db2_v97fp9_linuxamd64_s131204/vbs/engn/include/sqlbistorag
e_inlines.h HoldCount: 1
</LatchInformation>
These shows that the edu with thread id 233 handling the ALTER
TABLESPACE SWITCH ONLINE statement is having self dead latch. It
seems it has no knowledge that the latch was already obtained
previously, and continues waiting for it.
Line of Code:
The readLatch/writeLatch is likely obtained in
sqlbSwitchTablespaceOnline at line 3056 below:
3041 int SQLB_EXTERNAL sqlbSwitchTablespaceOnline
3042 (
3043 SQLB_POOL_ID poolID, // In: Tablespace ID
3044 SQLB_GLOBALS *glob // In: Globals
3045 )
3046 {
3047 int rc = 0;
3048 int ffstID = 0;
3049 SQLB_POOL_CB *pdef = sqlbGetExistingPoolDef(glob,
poolID);
3050 Bool poolLatched = FALSE;
//@d101806kws
3051
3052 pdTraceEntry1( SQLT_sqlbSwitchTablespaceOnline,
3053 PD_SQLB_POOL_ID(poolID) );
3054
//@d153736xlw
3055 //sqlbLatchPool (glob, poolID,
SQLO_LATCH_MODE_EXCLUSIVE);
3056 sqlbLatchPoolForReadWrite(glob, poolID);
//@d152158jzl
3057 poolLatched = TRUE;
//@d101806kws
In sqlbTrackMultipleModifications, the edu tries to get the
readLatch again:
4017 void sqlbTrackMultipleModifications (
SQLB_DIRECT_WRITE_CB *dwCB )
4018 {
4019 SQLB_GLOBALS *glob = dwCB->globals;
4020 SQLB_PAGE_HEAD *pageHead = NULL;
4021 SQLB_PAGE *page = NULL;
4022 SQLB_POOL_CB *pdef = NULL;
4023 SQLB_POOL_ID poolID =
SQLB_OBJECTP_ObjID(dwCB->obj).poolID;
4024 Uint numPages = 0;
4025 Uint pageIndex = 0;
4026
4027
//@db237504jrt
4028 // If the 'already hold poolR latch' bit is set in
the in direct write CB,
4029 // then dont bother latching the pool - we already
have it
4030 if (!((dwCB->latchesHeld & SQLB_DWCB_POOLR_HELD) ==
SQLB_DWCB_POOLR_HELD))
4031 {
4032 sqlbLatchPoolForRead(glob, poolID);
4033 } |
