Hi,
on DB2 v9.5 FP2 on Linux I wrote backup script that backups production DB2 database. This backup includes logs into backup image. Command is:
db2 backup db MYDB online to /db2/arhiv/ include logs
Parameter LOGARCHMETH1 is set to DISK:/db2/on_line_logs/ this is the path where archive logs are saved.

Then this script copies backup image to test computer to /delovni/arhiv directory and makes a restore of database.
Commands:
db2 "restore database MYDB from /delovni/arhiv to /delovni/db2baza into MYDB logtarget /delovni/restore_logs"

Message returned: "DB20000I The RESTORE DATABASE command completed successfully."

Then rollforward is executed:
db2 "rollforward db MYDB to end of logs and stop overflow log path (/delovni/restore_logs)"

And error is produces:
SQL1265N The archive log file "S0119839.LOG" is not associated with the
current log sequence for database "MYDB" on node "0".

I have checked directory /delovni/restore_logs and there is no file S0119839.LOG:
-rw------- 1 db2inst1 db2iadm1 4202496 2009-09-18 06:12 S0119837.LOG
-rw------- 1 db2inst1 db2iadm1 1740800 2009-09-18 06:12 S0119838.LOG


It is strange, now 8 months this script has been working without any error and nobody has changed any settings related to backup. But now error has appeared.

Any idea why this error accours?
Regards

The "overflow log path" is only used when there are no logfiles found in the regular log path. Make sure this path is empty before you start the rollforward!

Make sure the logtarget directory is empty before you do the restore specifying the logtarget path.

Logtarget is empty before restore is done...

I have some kind solve the problem. Let me explain how:

As I understand rollforward process is trying to also restore "archive logs" that are not available in backup image.

So I have changed rollforward command from:
db2 "rollforward db MYDB to end of logs and stop overflow log path (/delovni/restore_logs)"
to:
db2 "rollforward db MYDB to end of logs and stop overflow log path (/delovni/restore_logs) noretrieve"

I have checked documentation:
===============
NORETRIEVE
Allows the user to control which log files to be rolled forward on the standby machine by allowing the user to disable the retrieval of archived logs. The benefits of this are:
* By controlling the logfiles to be rolled forward, one can ensure that the standby machine is X hours behind the production machine, to prevent the user affecting both systems.
* If the standby system does not have access to archive (eg. if TSM is the archive, it only allows the original machine to retrieve the files)
* It might also be possible that while the production system is archiving a file, the standby system is retrieving the same file, and it might then get an incomplete log file. Noretrieve would solve this problem.
===============

What I can't understand is why rollforward process was working without any problem at all for 8 months, but now suddenly two days a role the same problem appeared.

Any idea what could trigger this problem?
Regards

I think it just depends on whether a unit of work spans log files (past the last log file in your overflow log path). DB2 has the option of trying to find the next log file in the archives to apply the rest of any open UOW's from the last log in the overflow log path, or it can just roll back any uncommited transactions if you specify noretrieve.

By the way, what is better to have multiple small log files or few big log files?
Now my db cfg settings are:
LOGFILSIZ= 1024
LOGPRIMARY = 10
LOGSECOND = -1

What I want to add to this subject is this:

Restoring prod_db's down the OTAP lane is a hidious operation, especially when youre source is an online-backup. Topic-starter knows, because the backup is taken with the "include logs" parameter and the logs are also retrieved during restore. Still: for us humans it is 'not done' to distinguish 1 log-file from the other (1 is was included in the backup-image and required in the rollback, the other was written by the "test" database prior to the restore-session).
So, just before you start your restore-script delete/move/zip/tar/whatever all the log-files you can find. Don't care, as long as they are GONE from that server!

This brings me to a tip and an answer to your latest question:
make sure that all your databases use different size for the logs. This will give you a little help in recognizing the soure-database of your logfiles. Something like:
this subdir is populated with 16M log-files, so that's prod
this subdir is populated with 10M log-files, so that's test etc etc

Larger log files will give you better performance, but slightly longer crash recovery times (very slightly longer unless your file sizes are extremely large). I would suggest larger file sizes so long as you don't over-do it. But you don't need to make the file size larger if you only use just a few log files per day at your current size.

I would not go below 4 logs files in the primary regardless of file size.

I don't see unlimited secondary (-1) very often because I do not believe it is supported with HADR.

Hi,
what is the best way to check how large should log files be?
Regards

If nobody knows (seems to be the case here) rely on :
DB2 Universal Database