IBM Support

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

Fixes are available

DB2 Version 9.5 Fix Pack 3b for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 2a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 2  for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4  for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

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
            

            
            
          

        


        

        


      


    


  





    

  



  
    
      

      
Page Feedback