Prev: Error DIA5000C A DRDA as Token "RECOVERABLE" was detected
Next: Funny error message UDB v8.2 linux
From: Ultrak The DBA on 4 May 2007 11:11
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

From: Ian on 4 May 2007 13:21
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.


From: Ian on 4 May 2007 13:22
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.


 | 
Pages: 1
Prev: Error DIA5000C A DRDA as Token "RECOVERABLE" was detected
Next: Funny error message UDB v8.2 linux