If a LOAD was abruptly interrupted or killed in an "unclean" way
(e.g. doing a "kill -9" on the client application process that
submitted the LOAD operation), the next LOAD into the same table
may encounter a delay of at least 1 minute at startup time, with
messages in db2diag.log like
2012-05-09-16.54.11.698719-240 I3736483E780 LEVEL:
Warning
PID : 6642 TID : 46912954689856PROC :
db2sysc
INSTANCE: db2inst1 NODE : 000 DB : V97
APPHDL : 0-59 APPID:
*LOCAL.db2inst1.120509205342
AUTHID : DB2INST1
EDUID : 93 EDUNAME: db2agent (V97)
FUNCTION: DB2 UDB, database utilities,
sqluCreateLoadListElement, probe:15
DATA #1 : LOADID, PD_TYPE_LOADID, 45 bytes
LOADID: 93.2012-05-09-16.54.08.228691.0 (2;4)
MESSAGE : A Load synchronization element for this table already
exists and is
associated with a different application ID. Load will
wait briefly
before reusing this synchronization element and
continuing normally.
No user intervention is required.
... and then at least 1 minute later
2012-05-09-16.55.12.500705-240 I3766076E607 LEVEL:
Warning
PID : 6642 TID : 46912954689856PROC :
db2sysc
INSTANCE: db2inst1 NODE : 000 DB : V97
APPHDL : 0-59 APPID:
*LOCAL.db2inst1.120509205342
AUTHID : DB2INST1
EDUID : 93 EDUNAME: db2agent (V97)
FUNCTION: DB2 UDB, database utilities,
sqluCreateLoadListElement, probe:20
DATA #1 : LOADID, PD_TYPE_LOADID, 45 bytes
LOADID: 93.2012-05-09-16.54.08.228691.0 (2;4)
MESSAGE : The Load synchronization element is now being reused.
No user
intervention is required.
This APAR fix will proactively check if the previous application
that ran the LOAD still exists, and allow the current LOAD to
proceed immediately as soon as it determines the previous
application no longer exists. We will still see the same 2
messages above in db2diag.log, but there will be minimal delay
between them. |
