After an SQL routine is invoked, the routine data may be
retained in the package cache and reused on subsequent
invocations of the routine. When this occurs, certain XML
variable state information in the retained data is also reused.
This state information reflects the preceding invocation of the
routine and is no longer valid.
Once the problem is hit, the database manager returns error:
SQL1034C The database was damaged, so all applications
processing the
database were stopped. SQLSTATE=58031
In the db2diag.log we can see stack:
2015-06-01-07.48.38.222855-240 I2019A4585 LEVEL:
Severe (Origin)
PID : 6357500 TID : 2058 PROC :
db2sysc
INSTANCE: bastarma NODE : 000 DB :
PL5DB2
APPHDL : 0-139 APPID:
*LOCAL.bastarma.150601114225
AUTHID : BASTARMA HOSTNAME:
hotelaix16.torolab.ibm.com
EDUID : 2058 EDUNAME: db2agent (PL5DB2)
FUNCTION: DB2 UDB, Common Storage Layer,
sqldcsl_getRecDataAndLength, probe:2611
MESSAGE : ZRC=0x87A80001=-2019033087=SQLDCSL_BADPAGE "Bad Data
Page"
DIA8500C A data file error has occurred, record id is
"".
DATA #1 : signed integer, 8 bytes
0
DATA #2 : Hexdump, 20 bytes
0x0700000083592038 : 0000 0000 0000 0000 0FB4 0000 0FB3 0000
................
0x0700000083592048 : 0000 0014
....
CALLSTCK: (Static functions may not be resolved correctly, as
they are resolved to the nearest symbol)
[0] 0x090000010CB016FC
sqldcsl_fetchDirect__FP8sqeAgentP8SQLD_TCBP12SQLD_TCB_CSLP16SQLD
CSL_FETCH_CB + 0x2B8
[1] 0x090000010CB34188
sqldcsl_fetchRow__FP8sqeAgentP8SQLD_TCBP12SQLD_TCB_CSLP16SQLDCSL
_FETCH_CB + 0x104
[2] 0x0900000107E2F6B4
xmls_FetchRecord__FP11XMLSTORE_CBR8XMLS_XIDPPcPUsT4UcP13XMLS_WA_
TOKENPP8SQLD_TCB + 0x1544
[3] 0x0900000107E01D24
getNodeID__17xmlDataDescriptorFP11XMLSTORE_CBP17XmlsNidDescripto
r + 0x544
[4] 0x0900000107DF0798
deepCopy__17xmlDataDescriptorFP11XMLSTORE_CBP17xmlDataDescriptor
Ui + 0x728
[5] 0x090000010CA3863C
xmlddCopy__17xmlDataDescriptorFP11XMLSTORE_CBP17xmlDataDescripto
rUiPP8SQLD_TCB + 0x328
[6] 0x090000010CA954F4
performBindout__13pvmXMLManagerFUiP10sqlz_valueT2 + 0x3FC
[7] 0x090000010CA951E8
performBindout__13pvmXMLManagerFUiP10sqlz_valueT2 + 0xF0
[8] 0x090000010A642DF0
sqlribnoCbToZValueExecutePsm__FP14db2UCinterface + 0x2208
[9] 0xFFFFFFFFFFFFFFFC ?unknown + 0xFFFFFFFF
[10] 0x090000010A3D0864
@51@sqlribno_work__FP8sqlrr_cbP9sqlri_bnoi + 0xC4
[11] 0x090000010A3D0E50 sqlribno__FP8sqlrr_cb + 0x94
[12] 0x0900000109FAE38C
sqlriSectInvoke__FP8sqlrr_cbP12sqlri_opparm + 0xB4
...
Followed by details about bad page retrieved in the
sqldcsl_fetchRow:
2015-06-01-07.48.44.957672-240 I130265A7163 LEVEL:
Severe
PID : 6357500 TID : 2058 PROC :
db2sysc
INSTANCE: bastarma NODE : 000 DB :
PL5DB2
APPHDL : 0-139 APPID:
*LOCAL.bastarma.150601114225
AUTHID : BASTARMA HOSTNAME:
hotelaix16.torolab.ibm.com
EDUID : 2058 EDUNAME: db2agent (PL5DB2)
FUNCTION: DB2 UDB, Common Storage Layer, sqldcsl_fetchRow,
probe:613
MESSAGE : ZRC=0x87A80001=-2019033087=SQLDCSL_BADPAGE "Bad Data
Page"
DIA8500C A data file error has occurred, record id is
"".
DATA #1 : String, 16 bytes
SQLDCSL_FETCH_CB
DATA #2 : SQLDCSL_FETCH_CB, PD_TYPE_CSL_FETCHCB, 64 bytes
SQLDCSL_FETCH_CB: Size:64
x0000 fixCB
0x07000000300259e8
accessMethod: SQLB_POOL_RELATIVE
fixMode: 2 SQLBOLD
buffptr: 0x0000000000000000
bpdPtr: 0x0000000000000000
pageLsnOnXLatch: 0000000000000000
dmDebugHdl: 0
objectPageNum: 10
empDiskPageNum: 4294967295
unfixFlags: 1000000
dirtyState: SQLBCLEAN
fixInfoFlags: 0
regEDUid: 0
Pagekey: {pool:1;obj:2;type:134} PPNum:10
Obj: {pool:1;obj:2;type:134} Parent={1;2}
lifeLSN: 0601074838222608
tid: 0 0 0
extentAnchor: 0
initEmpPages: 0
...
This APAR fix is to enhance code to reinitialize variables in
the case where the PVM reuses the routine data. |
