Re: Flooding Log Files

So then you really believe that :
1)
the only way to go through 24 meg of redo so fast that the archiver can not keep up is on an index rebuild - especially on a 50 Gig database?
2)
Large redo logs by definition increase crash recovery time significantly?

3) There are no performance and recovery advantages to having all that redo information
online?

I'm bagging this thread

Jeremiah Wilton wrote:

> On Tue, 16 Feb 1999, jack dectis wrote:
>
> > The fact that an index is being rebuilt seems to me to be
> > almost irrelevent to the real problem. The real problem is that
> > there is only 24 meg of redo log and that can get used up in seconds
> > by some other operation without the unrecoverable option. He just happened
> > to hit it with the index rebuild.
> >
> > Conner's observation that 240 meg of redo was enough for his database
> > is a good point. I like real big redo logs to minimize log switches and to have
> > more redo
> > capability online without going to archives.
> >
> > The unrecoverable option can't be argued against but it won't fix the fundamental
> > problem. Fix the fundamental problem and the unrecoverable option won't make much
> > difference -
> > unless he is short of disk space.
>
> But the user made no indication that his existing log size was a probem
> anytime outside of rebuilding indexes. I would not characterize using log
> sizes that are practical as a problem. It will sure take his database
> less time to perform crash recovery than yours, since he has so much less
> to recover. There are many pros and cons to more or less frequest log
> switching and checkpointing, but doing what is practical for your usage is
> not problematic. Also, it is more efficient to not log index rebuilds.
> Why does anyone need those redo entries anyway? The worst that can happen
> is you would end up recovering from a backup before the index rebuild and
> having to build the index again.
>
> --
> Jeremiah Wilton http://www.wolfenet.com/~jeremiah
Received on Tue Feb 16 1999 - 11:11:41 CST