(888) 685-3101 ext. 2

Recently, we noticed on a staging environment that the LOGPRIMARY setting was set to 35, yet the number of logs on the log path was only 21.

Number of primary log files                (LOGPRIMARY) = 35                         35
 Number of secondary log files               (LOGSECOND) = 45                         45


db2inst1# ls -ltr
total 13440704

-rw-------   1 db2inst1   db2iadm1       512 Dec  1 19:10 SQLLPATH.TAG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 12:18 S0063132.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 13:32 S0063133.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 13:36 S0063134.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 14:36 S0063135.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 14:55 S0063136.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 15:51 S0063137.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 16:13 S0063138.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  6 18:02 S0063139.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  7 11:28 S0063140.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  7 14:17 S0063141.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  8 13:19 S0063142.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan  9 05:06 S0063143.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 11 09:26 S0063145.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 11 09:26 S0063144.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 11 10:25 S0063146.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 11 10:51 S0063147.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 11 11:17 S0063148.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 11 11:39 S0063149.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 16 17:37 S0063129.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 18 06:59 S0063130.LOG
-rw-------   1 db2inst1   db2iadm1   327688192 Jan 21 13:06 S0063131.LOG

How was anyone able to connect to the database if DB2 could not allocate the number of logs required? Well, here’s what actually happened. When DB2 was initially started, there was plenty of space on the filesystem where the log path is located, so db2 started fine and had 35 logs allocated. Eventually the space ran out (it is after all a staging environment), so DB2 stopped allocating more logs than the available space. To understand this better, here’s what happens behind the scenes. When a log file fills up, DB2 has to copy that log file to the archive log directory and then rename to allocate more logs. In this case, because there was no space to be able to do that, it just managed to continue functioning with the available resources. DB2 ignores that kind of error.

2015-10-21-16.33.04.258307-240 E1738A463          LEVEL: Event
/primary
  Block size        = 8192 bytes
  Total size        = 18169724928 bytes
  Free size         = 0 bytes
  Total # of inodes = 5664
  FS name           = 
  Mount point       = 
  FSID              = 18446744071563116545
  FS type name      = vxfs
  DIO/CIO mount opt = None
  Device type       = N/A
  FS type           = 0x2
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
  [0] 0xC00000001444B740
2015-10-22-09.35.16.499947-240 I172033A432        LEVEL: Info
PID     : 27322                TID  : 94445       PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
EDUID   : 94445                EDUNAME: db2loggr (SAMPLE) 0
FUNCTION: DB2 UDB, data protection services, sqlpgInitRecoverable, probe:8210
MESSAGE : Not able to allocate all primary log files due to DISK FULL. This
          error is ignored.

So, please make sure that you have plenty of space allocated to the filesystem where the logs reside. If DB2 is already up and running, it won’t complain. But, if for some reason you did not free up space and restarted the DB2 engine, you won’t be able to do that, till you free up space. Planning is key.

Share This