IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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

  • defect   => wsdbu00344528
    module   => engn_sqp
    fixed in => v95 + FP2 (s080811)
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    LI73573

  • Reported component name

    DB2 UDE ESE LIN

  • Reported component ID

    5765F4104

  • Reported release

    950

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-07-10

  • Closed date

    2009-06-22

  • Last modified date

    2009-06-22

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

    LI73572

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

Fix information

  • Fixed component name

    DB2 UDE ESE LIN

  • Fixed component ID

    5765F4104

Applicable component levels

  • R950 PSY

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEPGG","label":"DB2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"950","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
22 June 2009