Re: Logical log sizing
Posted in 1999
Topics: Server Administration, Logging & Checkpoints, Versions, Editions & End-of-Life
If you were not throwing your log files away one issue affecting the choice
of log size would be the granularity at which you want to be able to archive
the logs and the number of transactions you are willing to lose if the log
drives crash hard (of course they should be mirrored but we always hope for
the best and plan for the worst). Since you are tossing your logs into the
bit bucket it really does not matter. I'd probably lean toward configuring
55 50MB log files to get 2.75GB of logs (to allow for long transactions, cut
this to 26->30 logfiles if you already allowed for that).
Art S. Kagel
"Carlson@WHSmith" wrote:
>
> IDS 7.30.ucX
> HPUX 10.20
> LTAPEDEV /dev/null>
> I'm planning to implement some much needed maintenance on my systems
> within the next few weeks. One of the areas includes physical / logical
> log maintenance.
>
> A while back I threw out some extra logical log space; now it's time to
> make the sizing thereof a bit more realistic. I've determined that I'll
> use about 1250M of logical log space; the only issue is how large (or
> small) to make the logical log size. Currently, I'm using 2M and 5M log
> sizes.
>
> I've checked DejaNews and IIUG for some insight, but I've noticed that
> it appears to be a matter of personal taste. Any additional insight
> would be very appreciated.
>
> --
> John Carlson
> Informix DBA
> WHSmith USA
>
> #include std_disclaimer.h /* These are my opinions, not my company's
> opinion */
"Art S. Kagel" wrote:
>
> If you were not throwing your log files away one issue affecting the choice
> of log size would be the granularity at which you want to be able to archive
> the logs and the number of transactions you are willing to lose if the log
> drives crash hard (of course they should be mirrored but we always hope for
> the best and plan for the worst). Since you are tossing your logs into the
> bit bucket it really does not matter. I'd probably lean toward configuring
> 55 50MB log files to get 2.75GB of logs (to allow for long transactions, cut
> this to 26->30 logfiles if you already allowed for that).
>
> Art S. Kagel
>
So then conventional wisdom is to backup early and often when keeping
transaction logs? Makes sense then to create smaller logical log
files. How small should one go and how would this affect performance?
My guess is that performance would be affected a bit like LRU writes vs.
checkpoint writes in this area; a little bit all along as opposed to the
big write after a 10MB (or so) log file gets written to tape or disk.
BTW, I'd like to fully implement transaction logging . . . . . just need
a way around that onstat -c (dedicated terminal) requirement.
--
John Carlson
Informix DBA
WHSmith USA
#include std_disclaimer.h /* These are my opinions, not my company's
opinion */
In article <38552FB8.1A9EEA5A@bellsouth.net>, Carlson@WHSmith
<carlson1@bellsouth.net> writes
>So then conventional wisdom is to backup early and often when keeping
>transaction logs? Makes sense then to create smaller logical log
>files. How small should one go and how would this affect performance?
Yes, we use 1000 250Kb logical logs. Remember you can have up to
32767 logical logs. 32767*250Kb (1/4Mb) = 8Gb!!
No reason to have logical logs larger than 250Kb unless you have >8Gb
of open transactions. Also set LRU_PRESERVE=1 to preserve 1 logical
log for backing up the logs. With LBU_PRESERVE=1 you again want small
logical logs...
>My guess is that performance would be affected a bit like LRU writes vs.
>checkpoint writes in this area; a little bit all along as opposed to the
>big write after a 10MB (or so) log file gets written to tape or disk.
>
>BTW, I'd like to fully implement transaction logging . . . . . just need
>a way around that onstat -c (dedicated terminal) requirement.
>
>
>
--
David Williams
David Williams wrote:
>
> In article <38552FB8.1A9EEA5A@bellsouth.net>, Carlson@WHSmith
> <carlson1@bellsouth.net> writes
> >So then conventional wisdom is to backup early and often when keeping
> >transaction logs? Makes sense then to create smaller logical log
> >files. How small should one go and how would this affect performance?
>
> Yes, we use 1000 250Kb logical logs. Remember you can have up to
> 32767 logical logs. 32767*250Kb (1/4Mb) = 8Gb!!
>
> No reason to have logical logs larger than 250Kb unless you have >8Gb
> of open transactions. Also set LRU_PRESERVE=1 to preserve 1 logical
> log for backing up the logs. With LBU_PRESERVE=1 you again want small
> logical logs...
>
> >My guess is that performance would be affected a bit like LRU writes vs.
> >checkpoint writes in this area; a little bit all along as opposed to the
> >big write after a 10MB (or so) log file gets written to tape or disk.
> >
> >BTW, I'd like to fully implement transaction logging . . . . . just need
> >a way around that onstat -c (dedicated terminal) requirement.
> >
> >
> >
>
> --
> David Williams
Thanks for the insight.
--
John Carlson
Informix DBA
WHSmith USA
#include std_disclaimer.h /* These are my opinions, not my company's
opinion */