If a LOAD operation's db2lrid or db2lcfm EDU fails very early
(typically due to hitting out of memory situation) in a specific
function sqluInitLoadEDU(), it might later crash in cleanup
codepath and bring down the DB2 instance. The crashing EDU has
stack trace like this:
0x09000000280D8298
sqluGetNumActiveChildren__FP11SqluEduInfoUiT2b + 0x98
0x09000000267DCA68 iCleanUp__11sqluCRidderFi + 0x3A4
0x09000000267DE4E8 iCleanUp__11sqluCRidderFi + 0x11C
0x09000000284C17F8 sqluLoadEDUDriver__FPUcUi + 0x3D4
0x0900000027E233D4 sqloEDUEntry + 0x4A8
and db2diag.log will have error entries that point to hitting
error in sqluInitLoadEDU(); for example
2015-03-09-10.01.54.776417-240 I2861288A604 LEVEL:
Severe
PID : 37028076 TID : 260186 PROC :
db2sysc 0
INSTANCE: ########2 NODE : 000 DB :
ADWDB1
APPHDL : 0-13666 APPDB:
xx.xx.xx.33.48043.150309140114
AUTHID : ######## HOSTNAME: adws1
EDUID : 260186 EDUNAME: db2lcfm0 0
FUNCTION: DB2 UDB, database monitor, sqlmon_bpcb::init_bpcb,
probe:30
RETCODE : ZRC=0x8B0F0002=-1961951230=SQLO_NOMEM_DBH
"No memory available in 'Database Heap'"
DIA8302C No memory available in the database heap.
2015-03-09-10.01.54.777552-240 I2861893A603 LEVEL: Error
PID : 37028076 TID : 260186 PROC :
db2sysc 0
INSTANCE: ########2 NODE : 000 DB :
ADWDB1
APPHDL : 0-13666 APPDB:
xx.xx.xx.33.48043.150309140114
AUTHID : ######## HOSTNAME: adws1
EDUID : 260186 EDUNAME: db2lcfm0 0
FUNCTION: DB2 UDB, database utilities, sqluReportErrToDiag,
probe:0
DATA #1 : String, 137 bytes
LOADID: 183071.2015-03-09-10.01.48.458486.0 (62;32)
DB monitor init error: , 0, ffffffff8b0f0002, Detected in
file:sqluedus.C, Line:1588
This problem applies only to DB2 10.5 fixpack 5 and fixpack 6 |
