AIX 5.3
DB2 9.5 FP2a
SAP ECC 6.0

We normally have 20 transaction log files in the log path.
Our transaction logs get archived to TSM via TDP for SAP.
Recently, however, a transcation log seems to be archived alright, but remains in the log path or is retrieved back to it when the online backup occurs.

For example, the transction log names may be S0000101.LOG through S0000120.LOG, but S0000099.LOG would be there too.

When we have a transaction log there that is not part of the contiguous 20, we have trouble restoring the database to another system for a system refresh. If we confirm that the first log in use is in fact the first of the contiguous 20, then move the "bad" one out of the log path, then the system refresh works fine.

The following is an entry in db2diag.log that seems to be somehow related since it does appear when we have this issue, but I am uncertain what to do to resolve it. Any suggests is appreciated. Thanks in advance.

2009-01-14-07.11.38.095444-300 I59443A469 LEVEL: Warning
PID : 466976 TID : 5399 PROC : db2sysc 0
INSTANCE: db2erp NODE : 000
EDUID : 5399 EDUNAME: db2lfr (ERP) 0
FUNCTION: DB2 UDB, recovery manager, sqlplfrFMReadLog, probe:5150
MESSAGE : Found a log on a newer chain. Updating chain number. extNum /
chainId
DATA #1 : unsigned integer, 4 bytes
11151
DATA #2 : unsigned integer, 4 bytes
11

I am assuming that there are more than 20 logs from the beginning of the online backup until the end of the backup? If so, why don't you try to double the size of the log files to keep it under 20.

The SAP recommended config is in use:
Log file size (4KB) (LOGFILSIZ) = 16380
Number of primary log files (LOGPRIMARY) = 20
Number of secondary log files (LOGSECOND) = 40

Typically, at any given time, there are always only 20 transaction logs in the log path.

The number of log file in the log path is usually the number specified in the db config for the primary number. However, if a unit of work spans more than that number of log files, they may not be archived until that unit of work is done.

Even though SAP recommends a certain log file size, there is no problem in doubling the amount. Otherwise you will need to handle more than 20 log files in your process.

I will increase the number of logprimary.

What about the db2diag.log entry of the chain change though?
To my knowledge the log chain before the backup is the same as the chain after the backup.

I don't know what that is. If you want to know I would suggest you contact IBM support.

Increasing the number og log files had no effect.

Again, the "problem" log file seems to be archived properly, but DB2 is not subsequently removing it from the log path.

The "problem" log seems to always happen to be the first log that is included with the backup.