Re: Performance issue while loading large amount of data

From: Noons <nsouto_at_optusnet.com.au.nospam>
Date: 12 Jan 2003 11:34:37 GMT
Message-ID: <Xns9301E3662423Cmineminemine@210.49.20.254>

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in news:XnaU9.21831$jM5.59935_at_newsfeeds.bigpond.com and I quote:

>>

>
> Well, it implies getting on for 18 bytes per row, since the rowid of the
> record about to be inserted is stored in rollback. Small, perhaps. But not
> nothing.
>

Must be fairly new. In most of V8 I never got ANY roolback activity with pure INSERT (no indexes, vanilla table settings).

>
> Er, I could be wrong, but see above: there *is* some rollback generated on
> the table being inserted into. The rollback generated by an insert is not
> just for the recursive stuff.
>

More than willing to believe there is now. But for a long time, there wasn't any signfificant rollback. All needed to be done to reset the table on a failed long INSERT-only xaction was reset the hwm. That was bugger all rollback.

I used to load 10 million rows and hardly use any rollback at all (<10M). That was in 8.0, no LMT. With LMT, it would be even less I suppose?

Of course, as I said: vanilla table INSERT, no indexes. Something like PCTUSED set way high in a highly volatile table or FREELISTS > 1 and all that changes.

That reminds me: has anyone ever investigated the impact of PCTUSED set way high with multiple FREELISTS? What happens when a block becomes free for INSERT as a result of the high PCTUSED? Will it use more FREELISTS than specified or share them? It was never very clear in the doco and I don't think anyone ever bothered to find out in detail.

-- 
Cheers
Nuno Souto
nsouto_at_optusnet.com.au.nospam

Received on Sun Jan 12 2003 - 05:34:37 CST