By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,584 Members | 1,774 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,584 IT Pros & Developers. It's quick & easy.

secondary logs and logarchmeth1

P: n/a
We have logarchmeth1 set. Also, we have a monitoring script that
checks the gap between any log files in the active log directory. We
have just recently activated logarchmeth1 and what we have found is
that we have a large occurrance of gaps. IBM has told us this is
because the secondary logs are hanging out and will not leave the
active log directory until the database is inactive. Our application
is 24/7 so the databases do not become inactive much.

We have been manually going out and removing the offending log file.
The log file is in the logarchmeth1 directory and the active
directory.

We went to logarchmeth1 to have the whole process controlled by db2
udb. Does anyone have a solution for our issue. We can code (ksh) to
delete the file, but this sorta defeats the purpose.

Thank you for any thoughts,

Kermit Lowry
S1 Corp

May 4 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Ian
Ultrak The DBA wrote:
We have logarchmeth1 set. Also, we have a monitoring script that
checks the gap between any log files in the active log directory. We
have just recently activated logarchmeth1 and what we have found is
that we have a large occurrance of gaps. IBM has told us this is
because the secondary logs are hanging out and will not leave the
active log directory until the database is inactive. Our application
is 24/7 so the databases do not become inactive much.

We have been manually going out and removing the offending log file.
The log file is in the logarchmeth1 directory and the active
directory.
Is this actually causing a problem for you (other than just grating
against the normal DBA's obsessive-compulsive disorder)?

DB2 doesn't remove the secondary log files once they have been created
in order to avoid the overhead of having to create those files again
the next time a large transaction runs and exceeds the primary log
space. If this occurs, DB2 should reuse (by renaming) the secondary
log files.

Provided you have sufficient space in your log path for all primary
and secondary log files (and a little extra in case the log manager
falls a little behind), you shouldn't run into any real problems. If
this is the case and you ARE having problems (i.e. file system holding
log path is filling up) then this would appear to be a bug.

The other solution is, of course, to simply increase your primary log
space to minimize the requirement to allocate secondary logs.
May 4 '07 #2

P: n/a
Ian
Ultrak The DBA wrote:
We have logarchmeth1 set. Also, we have a monitoring script that
checks the gap between any log files in the active log directory. We
have just recently activated logarchmeth1 and what we have found is
that we have a large occurrance of gaps. IBM has told us this is
because the secondary logs are hanging out and will not leave the
active log directory until the database is inactive. Our application
is 24/7 so the databases do not become inactive much.

We have been manually going out and removing the offending log file.
The log file is in the logarchmeth1 directory and the active
directory.
Is this actually causing a problem for you (other than just grating
against the normal DBA's obsessive-compulsive disorder)?

DB2 doesn't remove the secondary log files once they have been created
in order to avoid the overhead of having to create those files again
the next time a large transaction runs and exceeds the primary log
space. If this occurs, DB2 should reuse (by renaming) the secondary
log files.

Provided you have sufficient space in your log path for all primary
and secondary log files (and a little extra in case the log manager
falls a little behind), you shouldn't run into any real problems. If
this is the case and you ARE having problems (i.e. file system holding
log path is filling up) then this would appear to be a bug.

The other solution is, of course, to simply increase your primary log
space to minimize the requirement to allocate secondary logs.
May 4 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.