Re: NOLOGGING option

"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
>
> ******************************************
>
>
Received on Wed Apr 24 2002 - 07:07:36 CDT