Re: NOLOGGING option

Steven wrote:

> "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
> news:3cc69d91$0$233$ed9e5944_at_reading.news.pipex.net...
> > "Bob Bain" <bob.bain_at_markelintl.com> wrote in message
> > news:Slwx8.253$jE.2609_at_news.uk.colt.net...
> > > Hi,
> > >
> > > NOLOGGING is such a great misnomer isn't it.
> > >
> > > We thought this would be the answer to all our questions but
> unfortunately
> > > it ain't, the only way to get around this (that I know, flame me if I'm
> > > wrong) is to take the database out archive redo mode, do your updates
> and
> > > then put it back in.....
> > >
> > > BTW have you noticed that the amount of redo generated in 8i is massive
> > > compared to earlier versions??
> > >
> > > Cheers
> > >
> > > Bob
> >
> > Depends what your 'problem' is. If the problem is that your archive log
> > destination is filling too rapidly then your suggestion will 'fix' that
> > problem at the expense of recoverability. If on the other hand the problem
> > is with the redo IO then your 'fix' will lose recoverability and make no
> > difference at all to redo IO.
> >
>
> Well the problem is we are generating a number of report tables and this
> seems to generate a lot of redo information. I guess my only option is to
> build a seperate database for the reports from that of our main data.
> Recovery is of no importance for our reports but is an issue with all our
> other data.
>
> Thanks for your help guys.
> Steve.
>
> >
> > --
> > Niall Litchfield
> > Oracle DBA
> > Audit Commission UK
> > *****************************************
> > Please include version and platform
> > and SQL where applicable
> > It makes life easier and increases the
> > likelihood of a good answer
> >
> > ******************************************
> >
> >

I wouldn't be thinking "build a new database" as much as I'd be thinking build a new schema in the existing database in its own tablespace(s). Then mark those tablespaces READONLY during the reporting phase.

But I would suggest that you take Niall's suggestion a bit more seriously. It is possible that your real issue is that your log files are far from optimal in their size and number or that other configurable aspects of the logging process could be greatly improved.

Daniel Morgan Received on Wed Apr 24 2002 - 10:01:02 CDT