DB2 starts a child process for a number of database operations,
e.g. backup, log archive, load from federated data source or
load with load copy yes TSM option.
The child process that is created , inherits the file handles of
the parent process and closes them after the fork api call
completes.
On busy systems, the delay in the execution of the fork can
cause the parent process to receive "ETXTBSY" - file sharing
errors whilst the fork call takes place.
The DB2 code has a retry loop to handle retry the operation when
receiving such an error, but sometimes the delay is even longer
than this retry loop which may cause undesirable behaviour of
DB2, including in worst case scenario a panic of the server.
Note that in apar IC70039, the above mentioned retry loop was
already extended significantly.
This apar fix extends the retry logic of apar IC70039 even
further so that receiving the file sharing violation error
becomes near impossible.
An architectural solution for this problem has been deferred to
a major release
A typical db2diag.log error may show :
FUNCTION: DB2 UDB, oper system services, sqloopenp, probe:80
MESSAGE : ZRC=0x870F0016=-2029060074=SQLO_SHAR "File sharing
violation."
DIA8519C A file sharing violation has occurred,
filename was "".
CALLED : OS, -, open
The behaviour of the product will then depend on which area of
the code the error was received. |
