Re: table nologging in 8i

"Steve Haynes" <steve_at_rwx777.demon.co.uk> wrote in message news:CqcZWJAD5Ki5EwOe_at_rwx777.demon.co.uk...
> In article <3987edb6_at_news.iprimus.com.au>, Howard J. Rogers
> <howardjr_at_www.com> writes
> >
> >I may be mis-understanding your answer here, Steve, but since the syntax
 is
> >'alter table emp nologging', the idea that you can't put a table into no
> >logging mode is incorrect. Once issued, no subsequent DML statements on
> >that table will generate redo, until you explicity issue the 'alter table
> >emp logging' statement.
> >
> >You can even create an entire tablespace in nologging mode (hence all
> >segments created within the tablespace will not generate redo).
> >
> Yup, that's exactly what I thought......
>
> Your understanding and expectations are exactly as mine were.
> However, I continued digging and found that nologging only
> applies to the statement. ie: create tablespace nologging
> means exactly that.
> It doesn't mean no logging of any activity on this tablespace
> ever. (Now wouldn't that be nice?, hence my original interest
> in this feature).
>
> Now, this is where I got to.
>
> I'm not giving this as any kind of proof, and nor am I 100%
> on it, but I did canvass several respected opinions.
> I'd love a definitive statement from oracle, but I was unable
> to get one.
>
> Please tell me different!?.....

I'll tell you different. Since the creation of a tablespace doesn't generate redo in any case, it would be a bit odd to be able to switch of redo for the create tablespace statement. I don't know where you've been doing your digging, but I'd go back and dig some more!

A table remains in nologging mode until you explicity counteract the command, and the Backup and Recovery course I teach has explict warnings about forgetting to switch logging back on after a data load.

The statement at tablespace level means that it becomes the default for all segments created within that tablespace, for all time, unless you explicity use the 'logging' option when creating the segment.

Your sources are incorrect.
Regards
HJR
>
> This might be one to ask Tom....
>
> Steve
Received on Thu Aug 03 2000 - 00:00:00 CDT