Re: Pad temp extents a few bytes larger than sort_area_size?

Howard J. Rogers doodled thusly:

>So, to answer the original poster, no... stick to the exact setting of
>sort_area_size (or an integer multiple thereof), and don't pad it with extra
>bytes at all. You will pay a performance penalty if you do.
>

G'day, Howard:

I've been meaning to ask these ones, you might know the answers?

With the per session sort area size available now, isn't there a danger that some over-zealous developer will bring the temp tablespace calcs out the window with a changing sort area size?

I'm in two minds about this one. Should we set a large sort area size (say, 5M) to reduce I/O to temporary and set the uniform allocation to same size? Or set uniform to a sub-multiple? Or set sort area size smaller (say 500K) and set uniform to it exactly and wear a bit of I/O in exchange for better management of temporary?

See what I mean? Sure, the recommendations from Oracle make sense. What doesn't make sense is how people use the databases... ;-)

Come to think of it: with the per session sort area size, what's to stop a third party app from going waco on this and having each session with its own size? Can we see the currently used sort area size anywhere?

Sorry for the "bombardment" but I've been musing about these and can't find them discussed anywhere. Do you have anything on this?

Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam Received on Sun Mar 24 2002 - 06:20:00 CST