DB2 11.1.3.3 has a defect that can leave old log files in the active log path after they have been archived. If those files continue to accumulate, the filesystem can fill and the database can eventually become unavailable because it cannot create another transaction log.
IBM documents the problem in DB2 11.1.3.3 and 11.1.3.3 iFix 001 when both of these conditions apply:
- The database uses archive logging through
LOGARCHMETH1,LOGARCHMETH2or both. - A replication product or another process uses the
db2ReadLog()API.
This is fixed by APAR IT25556 in DB2 11.1.4.4. Upgrading to a fixed release is the proper solution. The registry change below is a temporary workaround for an affected system that cannot yet be upgraded.
Do not delete transaction logs just because they look old. DB2, replication and HADR may still require them. Follow IBM's diagnostic procedure and take a recoverable backup before moving any file from the active log path.
Confirm that this is the same problem
First confirm the exact DB2 level:
db2levelThen inspect the database log state:
db2pd -db DATABASE_NAME -logs
db2 get db cfg for DATABASE_NAMEReplace DATABASE_NAME with the database alias. Check the archive status, the next log to archive, the first active log and the active log path. A directory containing many files is not enough to identify this defect: active logs can legitimately remain there for crash recovery, HADR or a log-reading application.
If the database is not on one of the affected 11.1.3.3 levels, investigate the configured archive methods and their error status instead of applying this workaround.
Disable buffered reads temporarily
Run db2set as the DB2 instance owner:
db2set DB2_USE_BUFFERED_READ_FOR_ACTIVE_LOG=NOVerify the instance-level value:
db2set DB2_USE_BUFFERED_READ_FOR_ACTIVE_LOGRestarting the entire DB2 instance is unnecessary. IBM's defect note only requires the affected database to be deactivated and reactivated for this setting to take effect. Plan an outage, disconnect Maximo and any other clients cleanly, then run:
db2 deactivate db DATABASE_NAME
db2 activate db DATABASE_NAMEDo not force applications off unless that disruption is planned. After reactivation, DB2 should clean up unnecessary log files automatically. Continue monitoring the active log filesystem and confirm that archive processing succeeds.
Setting this variable to NO disables a performance improvement for rolling back large units of work. It should therefore remain a workaround rather than a permanent substitute for patching DB2.
Re-enable the feature after upgrading
After upgrading to DB2 11.1.4.4 or a later fixed release, re-enable buffered reads:
db2set DB2_USE_BUFFERED_READ_FOR_ACTIVE_LOG=YESDeactivate and reactivate the database again during a planned outage, then verify the setting and watch the active log path.