LI72087: DATABASE CRASH AS A RESULT OF MANUALLY REMOVING AN OLD LOG FILE IN AN ENVIRONMENT WHERE LOG MIRRORING IS TURNED ON.

APAR status

• Closed as program error.

Error description

• First, we should say that you should never remove a log file
  manually as this could lead to problems.  Even if the log file
  seems to be orphaned and the log file number is less than the
  first active log, it is still not safe to delete it.
  
  This is because DB2 does not delete log files normally.
  Instead, db2 will rename and re-use log files, and there are
  normal reasons when there might exist an older log file that
  is sitting in the log path waiting to be re-used.
  
  In a situation where mirrored logging is used, DB2 can encounter
  a case where if an older log file is removed, then later db2
  might try to re-use that older log file and find it missing and
  then hit a crash.
  
  The db2diag.log would look like this:
  
  2007-02-09-16.52.14.360582-300 E80737G342         LEVEL: Warning
  (OS)
  PID     : 14167                TID  : 4143781568  PROC :
  db2loggr
  INSTANCE: db2inst             NODE : 000         DB   : db
  FUNCTION: DB2 UDB, oper system services, sqloseek, probe:100
  CALLED  : OS, -, unspecified_system_function      OSERR: EBADF
  (9)
  
  2007-02-09-16.52.14.391016-300 I81080G332         LEVEL: Error
  PID     : 14167                TID  : 4143781568  PROC :
  db2loggr
  INSTANCE: db2inst             NODE : 000         DB   : db
  FUNCTION: DB2 UDB, data protection, sqlpgExtendLogFile,
  probe:540
  MESSAGE : Error -2045837302 while extending log file 54337
  
  So, although a user should never delete a log file, we will
  still clean this up so that db2 will just create a new log
  file instead of trying to re-use a non-existant log.
  

Local fix

• none, however the problem cannot happen if you don't manually
  delete log files.
  

Problem summary

• First, we should say that you should never remove a log file
  manually as this could lead to problems.  Even if the log file
  seems to be orphaned and the log file number is less than the
  first active log, it is still not safe to delete it.
  
  This is because DB2 does not delete log files normally.
  Instead, db2 will rename and re-use log files, and there are
  normal reasons when there might exist an older log file that
  is sitting in the log path waiting to be re-used.
  
  In a situation where mirrored logging is used, DB2 can encounter
  a case where if an older log file is removed, then later db2
  might try to re-use that older log file and find it missing and
  then hit a crash.
  
  The db2diag.log would look like this:
  
  2007-02-09-16.52.14.360582-300 E80737G342         LEVEL: Warning
  (OS)
  PID     : 14167                TID  : 4143781568  PROC :
  db2loggr
  INSTANCE: db2inst             NODE : 000         DB   : db
  FUNCTION: DB2 UDB, oper system services, sqloseek, probe:100
  CALLED  : OS, -, unspecified_system_function      OSERR: EBADF
  (9)
  
  2007-02-09-16.52.14.391016-300 I81080G332         LEVEL: Error
  PID     : 14167                TID  : 4143781568  PROC :
  db2loggr
  INSTANCE: db2inst             NODE : 000         DB   : db
  FUNCTION: DB2 UDB, data protection, sqlpgExtendLogFile,
  probe:540
  MESSAGE : Error -2045837302 while extending log file 54337
  
  So, although a user should never delete a log file, we will
  still clean this up so that db2 will just create a new log
  file instead of trying to re-use a non-existant log.
  

Problem conclusion

• The APAR is first fixed in the DB2 version 8, FixPak 17(s080813)
  

Temporary fix

• No
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  LI73572

Fix information

• Fixed component name

  DB2 UDE ESE LIN

• Fixed component ID

  5765F4104

Applicable component levels

• R820 PSY

     UP