Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: shutdown abort and database consistency

Re: shutdown abort and database consistency

From: Mark D Powell <mark.powell_at_eds.com>
Date: 10 Jul 2002 08:57:17 -0700
Message-ID: <178d2795.0207100757.50ca648d@posting.google.com>


mark_at_bobak.net (Mark J. Bobak) wrote in message news:<fe9b0e1b.0207091341.4216ddb1_at_posting.google.com>...
> Actually, Mark, for those operations for which NOLOGGING is valid, all
> redo AND undo writing is disabled, except for any recursive data dictionary
> updates which will go to undo and redo, and logging of extent invalidation
> records in redo (I don't think they go to undo, cause I don't think they make
> any sense there).
>
> In the case previously mentioned in this thread, clearly a DELETE operation
> will always log, so this is not a factor. However, the fact remains that
> NOLOGGING, when applied to an appropriate operation, will disable redo and
> undo.
>
> -Mark
>
> mark.powell_at_eds.com (Mark D Powell) wrote in message:
> >
> > Rick, the nologging option to my knowledge does not stop the recording
> > of rollback information. The recovery of uncommited transaction data
> > is still accomplished by Oracle through the reading and application of
> > information stored in the rollback segments. The redo log information
> > would have been read and applied during the crash recovery phase of
> > startup and then rollback would be applied to rollback incomplete
> > transactions. And because 8.1 and 9i open the database before
> > rollback is completed sessions can encounter the situation where they
> > must rollback data for incomplete transactions that occurred before
> > the crash. What does v$session_wait and v$transactions show for the
> > affected sessions?
> >
> > -- Mark D Powell --

[Second attemp to post due to timeout error so if the post shows twice...]

Mark, true enough. I was thinking about the original post which was as you fairly pointed out was a delete. I should have said something to the effect that basically all normal DML has to generate undo (rollback) and redo all the time, and that only certain DDL statements which accept the nologging option like create table as select and create index along with direct path operations like insert /*+ APPEND */ can bypass most redo and undo generation.

Received on Wed Jul 10 2002 - 10:57:17 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US