Re: Performance issue while loading large amount of data

Hi Ban,

Just to add a few additional points embedded ...

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:fMnV9.25069$jM5.66243_at_newsfeeds.bigpond.com...
>
> "Ban Spam" <ban-spam_at_operamail.com> wrote in message
> [big snip]
> >
> > 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
>
> Er, call me pedantic, but that's a 'DELETED upon a rollback'.
>
> And the above fails to take account of *anything* that Nuno and I have
been
> discussing for days, or which Richard's magisterial post resolved. Namely
> that 'it's not as simple as that, because there are different sorts of
> inserts'. Generalizing is fine, but not if it misses the entire point of
the
> (very extensive) thread.
>
> > UPDATE - Stores the changed fields (before the change is applied)
> > DELETE - Stores every field (so an INSERT could be done upon a ROLLBACK)

Note that there's a bit more than just the *old data* that gets recorded as undo. Note that all the block header details (such as previous SCN, previous ILT slot values, row directory changes, etc. ) all have to be recorded as well else consistent reads have zip chance of working. It's all thrown in there into the potting mix.

> >
> > WRT to REDO in increasing amount of redo generated (generalized)
> > SELECT - none because nothing needs to be "undone"

Not necessarily true. Delayed block cleanouts could result in selects making changes to blocks. There's always exceptions ...

Cheers ;)

Richard Received on Thu Jan 16 2003 - 07:45:39 CST