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    } |
