Db2 – Online backups with VENDOR library: what should be set for ACTIVE LOG PATH

You really should be reading manuals, not "pruning logs". Your database is set up for circular logging, which means there is nothing to "prune". If transactions occasionally require extra log space, increase the value of LOGSECOND. Too many primary logs will slow down the database startup, as they are preallocated. Secondary logs are allocated as needed, they will remain in the active log directory until the database is restarted.

"Pruning logs" will not affect the amount of active log space (with one exception that I will mention later): it is dictated purely by the sum of LOGPRIMARY and LOGSECOND, multiplied by LOGFILSIZ. If you were using the archive log mode, you would be able to remove older archived log files to free up some disk space, but the amount of active log space would not change. Even then, you would delete logs created prior to the previous backup, not prior to the first active log file.

Only if your archived logs and active logs share the same file system (which is not a good idea in itself), the uncontrolled accumulation of archived logs may prevent the active log space to grow, when necessary, to its configured maximum size.

LOGPRIMARY, LOGSECOND and LOGFILSIZ combine to define the maximum size of the transaction log on your server using the following formula:

Total Size = (LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4096 bytes

In your case, this results in (13 + 15) * 4096 * 4096 = 469762048 bytes.

The maximum transaction log size limits 2 things:

1) the absolute size of a single transaction 2) the "timespan" between the oldest active transaction and the newest transaction.

You need to make it large enough to handle both scenarios, although if you're running into problems relating to #2 then you really have a problem with a poorly-behaved app that isn't committing.

Choosing an appropriate value for LOGFILSIZ should be based on how regularly you want to archive log files, as this will have an effect on your recoverability in the event of a problem. If your database archives log files only once every hour (or less), you will potentially lose much more data in the event of a serious problem than if your database archives a log file every 2-3 minutes (because every time a log file is archived it should be copied to NetBackup).