开启DB2_CAPTURE_LOCKTIMEOUT后未生成db2locktimeout日志求助

Alright, let's break down why you're not seeing the db2locktimeout logs even though you successfully triggered a lock timeout (reason code 68, SQLSTATE 40001). These are the most common missteps to check:

• You didn't restart the DB2 instance after setting the parameter
  DB2_CAPTURE_LOCKTIMEOUT is an instance-level setting — just running db2set updates the registry, but the running instance won't apply the change until you restart it. You can confirm if the active instance is actually using the ON setting by running:

  db2 get dbm cfg | grep CAPTURE_LOCKTIMEOUT
  

  If it still says OFF, fix this with a quick restart:

  db2stop force
  db2start
  

  Recheck the active config after restarting to make sure it's now ON.

• The database-level CAPTURE_LOCKTIMEOUT parameter is overriding the instance setting
  DB2 lets database-specific settings take priority over instance-level ones. Even if your instance has DB2_CAPTURE_LOCKTIMEOUT set to ON, if the database you're testing with has its own CAPTURE LOCK TIMEOUT set to NO, no logs will be generated. Check this with:

  db2 get db cfg for YOUR_DB_NAME | grep CAPTURE_LOCKTIMEOUT
  

  If it returns NO, update it with:

  db2 update db cfg for YOUR_DB_NAME using CAPTURE_LOCKTIMEOUT YES
  

  This change takes effect right away — no restart needed.

• The db2dump directory has incorrect permissions
  The db2inst1 user needs write access to /home/db2inst1/sqllib/db2dump to create the lock timeout logs. Run this to check the directory's permissions and ownership:

  ls -ld /home/db2inst1/sqllib/db2dump
  

  Make sure the owner is db2inst1 (and the group is usually db2iadm1) and permissions are at least 700 (read/write/execute for the owner only) or 755. If not, fix it with:

  chown db2inst1:db2iadm1 /home/db2inst1/sqllib/db2dump
  chmod 700 /home/db2inst1/sqllib/db2dump
  

• Your monitor heap size is too small
  DB2 relies on the monitor heap to collect and store lock timeout data. If MON_HEAP_SZ is set to a tiny fixed value, it might not have enough resources to generate the log file. Check your current setting:

  db2 get dbm cfg | grep MON_HEAP_SZ
  

  If it's a low fixed number (like 256), switch it to automatic so DB2 manages it dynamically, or increase the value:

  db2 update dbm cfg using MON_HEAP_SZ AUTOMATIC
  db2stop force
  db2start
  

• You're testing a system-level transaction (unlikely, but worth checking)
  The db2locktimeout logs are only generated for user-initiated transactions that hit lock timeouts. If your test scenario was using a system-level task (like internal DB2 maintenance), it won't trigger the log. Double-check that your test uses regular user connections and transactions.

内容的提问来源于stack exchange，提问作者Panadol Chong