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

logfile on db2

P: n/a
Hi ,

I have an issue about logfile on db2 .

My database (v7.2) is on linux ES 2.2 .

The logretain is equal to recovery and userexit is off (for replication
purpose that doesn't work anymore) .

My end user want to keep the log (in case of ...) but want to move it
to another folder and pruning it later (if the overhaul of those
logfiles is succesful means doesn't crash the database) .

Is it possible ?

Thx !

Andy the beginner in DB2 .

Nov 12 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Hi,

Andy K wrote:
The logretain is equal to recovery and userexit is off (for replication
purpose that doesn't work anymore) .

My end user want to keep the log (in case of ...) but want to move it
to another folder and pruning it later (if the overhaul of those
logfiles is succesful means doesn't crash the database) .

Is it possible ?


easiest way to do this is switching userexit to ON, modify one of the
userexit-samples in sqllib/samples/c/ and archive all files to a
network-mount.

Pruning old files is another issue. I wrote a perl-script which looks
for the timestamp of the oldest backup image, retrieves the first
logfile needed from the "list history" command and then prunes the older
LOGs.

8.2 would give you the possibility to configure the path for your logs
using logarchmeth1 etc. and you would not need the userexit any more.

8.2.2 introduces the ADMIN_LIST_HIST() table function which makes
analysis of the database history much easier for non-C Programmers.

Hope that helps.

regards,

Norbert
Nov 12 '05 #2

P: n/a
Hi Norbert ,

Thanks for your answer.

i have an another question .

The userexit option is good for automatic 'archiving and removing (not
pruning)' .

But I want to do it manually ...

Is it good enough if I do a 'db2 get db cfg for <dbname>' , check the
name of the first active log and remove all the log minus 2 the current
log (if my current is 3080 , I'll remove everything before 3078) ?

Thanks !

Andy the beginner in DB2

Nov 12 '05 #3

P: n/a
Hi Andy,

Andy K wrote:
The userexit option is good for automatic 'archiving and removing (not
pruning)' .
well...
But I want to do it manually ...
OK. I personally donīt believe much in manual processes...
Is it good enough if I do a 'db2 get db cfg for <dbname>' , check the
name of the first active log and remove all the log minus 2 the current
log (if my current is 3080 , I'll remove everything before 3078) ?
Should work. Test it on a separate system and good luck. ;-)
As you will need the logs for recovery, you should copy them to a remote
filesystem/tape/somedevice _before_ you remove them.

Just my 2 ctīs
Thanks !


welcome,

Norbert

Nov 12 '05 #4

P: n/a
>
But I want to do it manually ...

OK. I personally donīt believe much in manual processes...


What are you going to do when the log directory runs out of space at 3AM?

Larry Edelstein
Nov 12 '05 #5

P: n/a
Tim
Also you'll need to consider the problem of a transaction spanning more
than one log file. You could wind up in a situation where the current
log only contains part of the transaction and should you remove the
older files rolling back will present a problem.

Nov 12 '05 #6

P: n/a
Hi,

Larry wrote:

What are you going to do when the log directory runs out of space at 3AM?


Thinking about what I have missed to do _before_ this happened?

As I like to sleep at night, I took care this canīt possibly happen.

- I know, how much I have configured for logging
- I do automated checks on log-usage to determine if I need to set up
more logs
- The device holding the logs is big enough to hold at least a 2 days
span of logs (in case, log archiving is running into errors over the
weekend).
- userexit (or LOGARCHMETHOD1, whatever) moves away archived logs
- if log archiving (incl. FAILOVER) fails -> pager-alarm
- if any of the used devices is running out of space -> pager-alarm
- automated offsite-copies of all logs
- automated pruning of logs that are not needed for existing db-backups

With reasonable alarm thresholds, my system monitoring framework should
keep me informed about upcoming trouble like that during daytime work hours.

regards,

Norbert

Nov 12 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.