Re: Performance issue while loading large amount of data

From: Ban Spam <ban-spam_at_operamail.com>
Date: Thu, 16 Jan 2003 01:20:45 GMT
Message-ID: <Xns9304B0B91E72DSunnySD@68.6.19.6>

"Richard Foote" <richard.foote_at_bigpond.com> wrote in news:RdcV9.24793$jM5.65715_at_newsfeeds.bigpond.com:

> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> news:EzZU9.24111$jM5.64133_at_newsfeeds.bigpond.com...
>

><big almighty snip>

>

>> Time to start block dumping, I think.

>
> Hi Guys,
>
> OK, kids are in bed, time to do some investigating (and starting by
> looking at a few block dumps is a good way to go).
>
> As I said somewhere previously, inserts most certainly do generate
> undo, they must for rollback, read consistency reasons, etc. pretty
> well as Howard has said.

WRT to ROLLBACK in increasing amount of undo generated (generalized)

SELECT - none because nothing needs to be "undone"
INSERT - stores the ROWID so the row could be DROPPED upon a ROLLBACK
UPDATE - Stores the changed fields (before the change is applied)
DELETE - Stores every field (so an INSERT could be done upon a ROLLBACK)

WRT to REDO in increasing amount of redo generated (generalized)

SELECT - none because nothing needs to be "undone"
DELETE - stores the ROWID 
UPDATE - Stores the changed fields (after the change is applied)
INSERT - Stores every field 

So INSERT, UPDATE, & DELETE inclusive ALL generate both REDO & UNDO; each in varying amounts. Received on Wed Jan 15 2003 - 19:20:45 CST