DB2 FOR LUW / DB2FORLUW / B10 - DB2

This is a very rare race deadlatch/loop condition between two
db2 edus.
The first edu is servicing a manual database memory decrease.
To satisfy this request it tries to reduce the size of a buffer
pool.
This size reduction can only complete when there are no further
pinned buffer pool pages in the pages that will be discarded.
When such pages are seen, the agent waits until those are no
longer pinned. ( pinned typically means that another agent is
actively using those pages )

This wait is what we see in the waiter stack :

0x0900000000112014 thread_wait + 0x94
0x09000000212FD520 sqloWaitEDUWaitPost + 0x248
0x090000001E26A080
sqlbResizeBufferPool__FP15SQLB_BufferPoolP21SQLB_BP_UC_ALTER_INF
OP12SQLB_GLOBALS + 0xA20
0x090000001E26E564
sqlbResizeBufferPool__FP15SQLB_BufferPoolP21SQLB_BP_UC_ALTER_INF
OP12SQLB_GLOBALS + 0x246C
0x090000001E26F128
sqlbResizeBufferPool__FP15SQLB_BufferPoolP21SQLB_BP_UC_ALTER_INF
OP12SQLB_GLOBALS + 0x3030
0x090000001FF0D640
sqlbAlterAutomaticBufferPool__FPcUiiP8sqeAgent + 0xAE8
0x0900000022909EBC
sqlrlStmmAlterBufferPool__FP8sqeAgentPciT3P14db2UCinterfaceP5sql
ca + 0x448
0x090000002290AAB8
sqlbScaleAutoBPsByFactor__FP8sqeAgentP10sqlf_dbcfdPcdPUlb +
0x818
0x0900000022906204
stmmScaleAutosOnDBMemDecrease__FUlT1P16sqeLocalDatabase + 0x16F4
0x0900000022C154E4
sqlf_dynamic_db_update__FP16sqeLocalDatabaseP11db2CfgParamP10sql
f_dbcfdP5sqlca + 0xB604
0x0900000022C1516C
sqlf_dynamic_db_update__FP16sqeLocalDatabaseP11db2CfgParamP10sql
f_dbcfdP5sqlca + 0xB28C

In the latch information of the stack file, we can see it is
also holding a latch to protect the database configuration from
concurrent updates :


Holding Latch type: (SQLO_LT_SQLE_KRCB__cfg_change_latch) -
Address: (0x78000000045a3d8), Line: 4608, File: sqlf_db_op.C
HoldCount: 1


The session which then holds the pinned page, has to wait as
well because it is in a code path where it dynamically wants to
adjust the sort heap.
It loops endlessly in  stmmUpdateDBConfig as seen in this stack:

  0x0900000000564910 _p_nsleep + 0x10
  0x0900000000039364 nsleep + 0xE4
  0x090000000015E310 nanosleep + 0x190
  0x0900000004204008 ossSleep + 0xA8
  0x090000002067236C sqlorest + 0x188
  0x0900000022CCD1C8
sqlfUpdateDbCfg__FP16sqeLocalDatabaseP6db2CfgUiiT4P5sqlcas +
0x1C50
  0x0900000022C49E04
sqlfUpdateDbCfg__FP16sqeLocalDatabaseP6db2CfgUiiT4P5sqlcas +
0x4C1C
  0x0900000022C5D904
sqlfDispatchDbCfgUpdate__FP16sqeLocalDatabaseP6db2CfgiT3P5sqlca
+ 0x110
  0x09000000228FCF14
stmmUpdateDBConfig__FP16sqeLocalDatabaseUlPclbN25 + 0x1F8
  0x09000000228FCCC4
stmmUpdateSortHeap__FP16sqeLocalDatabaseUibT3 + 0x30
  0x0900000020184E6C
stmmReactToSHeapThresOverflowOrMinSortHeap__FP16sqeLocalDatabase
Pb + 0x4F4
  0x090000002320BDF4
sqlri_hsjnFlushSinglePartition__FP8sqlrr_cbP11sqlri_hsjnolP20sql
ri_hsjnTupleBlock + 0x960

This is because it needs to obtain the latch held by the first
session. It assumes that the STMM edu holds this latch and goes
into a wait loop for the STMM to release the latch.
However, because of the manual database_memory decrease, STMM
has been paused until that decrease completes. So this loop is
also infinite and hence the pinned page is never released and
the first session also never makes progress.

****************************************************************
* USERS AFFECTED:                                              *
* ALL                                                          *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* See Problem Description above.                               *
****************************************************************
* RECOMMENDATION:                                              *
* Upgrade to DB2 Version 11.1 Fix Pack 2.                      *
****************************************************************

not known / see Local fix

forerunner  : IT19768 
follow-up : 

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

09.08.2017
10.10.2017
10.10.2017