With infinite logging enabled, in environments where new
transactional log files are produced very often, active
transactions might get stuck waiting for new logs to be
allocated.
For problem to occur following conditions must be true:
1. Infinite logging must be enabled (LOGSECOND -1)
2. New logs have to be produced more often than ARCHRETRYDELAY
database parameter is set. Usually this is the case when
LOGFILSIZ is set to very low value.
3. There is a transaction that spans across more than 256 logs
4. In the past there was a failed log archival.
Before problem occurs, multiple errors about failed FAILARCHPATH
cleanup will be logged, e.g:
2014-12-17-15.44.03.984770+060 E11404703E482 LEVEL:
Warning
PID : 4626 TID : 46912937912064 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB :
SAMPLE
HOSTNAME: db2host
EDUID : 37 EDUNAME: db2logmgr (SAMPLE) 0
FUNCTION: DB2 UDB, data protection services,
sqlpgCleanFailArchPath, probe:4920
DATA #1 :
Unable to find log file 339345 for LOGARCHMETH1. Assume log was
archived and continue.
As the result following message will be logged in db2diag.log:
2015-01-07-04.10.49.832799+060 E3366782E519 LEVEL:
Warning
PID : 17323 TID : 46912874997504 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB :
SAMPLE
HOSTNAME: db2host
EDUID : 62 EDUNAME: db2loggr (SAMPLE) 0
FUNCTION: DB2 UDB, data protection services, sqlpgadf, probe:540
DATA #1 :
Maximum allowable unarchived log files reached.
DB2 will continue to reissue archive requests.
Check that log archiving is working properly.
despite the fact that currently log archival is working
properly.
Active transaction will get stuck in Commit active or Compiling
state, with following functions on the top of the stack:
sqlpgResSpace
sqlpWriteLR
and waiting for SQLO_LT_SQLP_DBCB__add_logspace_sem latch. |
