A pureScale instance may panic while a bufferpool decrease
operation is running. Bufferpool decrease can be initiated from
STMM or by explicitly resizing a bufferpool to a smaller size.
This is a very rare timing issue and the likelihood to hit the
issue is very low. The panic will be reported by an agent
indicating that a page latch is not held, similar to the
following db2diag.log message:
FUNCTION: DB2 UDB, SQO Latch Tracing,
SQLO_SLATCH_CAS64::releaseConflict, probe:330
MESSAGE :
ZRC=0x870F011E=-2029059810=SQLO_LATCH_ERROR_EXPECTED_HELD
"expected latch to be held."
CALLED : OS, -, unspecified_system_function
DATA #1 : String, 39 bytes
Attempting to unlock an invalid latch:
DATA #2 : File name, 16 bytes
sqloLatchCAS64.C
DATA #3 : Source file line number, 8 bytes
1054
DATA #4 : Codepath, 8 bytes
2
DATA #5 : String, 125 bytes
0x0000000000000000: {
held X: 0
reserved for X: 0
shared holders: 0
firstSharIndex: 0x0
firstExclIndex: 0x0
}
DATA #6 : LatchMode, PD_TYPE_LATCH_MODE, 8 bytes
0x0 (invalid mode)
DATA #7 : String, 399 bytes
{
state = 0x0000000000000000
= {
held X: 0
reserved for X: 0
shared holders: 0
firstSharIndex: 0x0
firstExclIndex: 0x0
}
starve X mode = false
xWaitCount = 0
requestCount = 0
identity = SQLB_BPD::bpdLatch_SX (264)
}
DATA #8 : Pointer, 8 bytes
0x0a000302d59785d8
The latch information in the trap file in the FODC directory
will indicate the agent is holding a page latch in mode: S.
Holding Latch type: (SQLO_LT_SQLP_SAVEPOINTS__spLatch) -
Address: (0xa000301836b8680)
Holding Latch type: (SQLO_LT_SQLP_TENTRY__applLatch) - Address:
(0xa000301836b8cf0), Line: 873, File: sqlpxreg.C HoldCount: 1
Holding latch type: (SQLO_LT_SQLB_BPD__bpdLatch_SX) - Address:
(0xa0003031e7e9968), mode: S, Line: 1650, File: sqlbfix.C |
