Re: Flooding Log Files

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.

Jeremiah Wilton wrote:

> Maybe the user should just ALTER INDEX REBUILD... NOLOGGING, and
> forget about resizing redologs. What's the use of logging an index
> create? The next backup will get them anyway.
>
> --
> Jeremiah Wilton http://www.wolfenet.com/~jeremiah
>
> On Mon, 15 Feb 1999, jack dectis wrote:
> >
> > At the very least your log files should be much larger
> >
> > Maybe 100 - 500 meg each for starters.
> >
> > Maybe your log source and archive destination disks need to
> >
> > dedicated to those purposes as well if you really crank out the updates.
> >
> > Van Messner wrote:
> >
> > > One of our databases has 4 log groups of size 6M each (2 members per
> > > group). The other day I used an alter index..rebuild to rebuld a 300MB
> > > index that had thrown 100 extents. ARCH had trouble keeping up and I could
> > > see from the alert log that log groups filled faster than they could be
> > > archived. The rebuild took about fifteen minutes and not much else was
> > > putting a load on the database at the time.
> > > Is index rebuilding generally this demanding of ARCH? And if the index
> > > is in an "INDEX" tablespace should the rebuild need resources from the
> > > SYSTEM tablespace?
Received on Tue Feb 16 1999 - 10:24:14 CST