Re: Looking for Statspack documentation

From: Noons <nsouto_at_optusnet.com.au.nospam>
Date: 08 Feb 2003 14:37:59 GMT
Message-ID: <Xns931DE2E98F76mineminemine@210.49.20.254>

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in news:0DX0a.42904$jM5.108657_at_newsfeeds.bigpond.com and I quote:

>>
>> That is news.  Prime?

>
> Jonathan's been saying this for years. You get 'popular' freelists if
> the number of freelists isn't prime, which rather defeats the purpose of
> multiple freelists in the first place.

Yeah, I know. But since when? 8.0? 8i? Before? I'm quite sure I read somewhere in the old Oracle manuals to set it to the number of CPU's or something of the ilk. The prime stuff, I've only seen it in Jonathan's stuff.

>>
>>
>> Might be useful to explain how.  SOme folks out there don't,
>> believe me.

>
> Surely not ;-) I might be missing something, but it's basic mathematics

Missed. Not why. How. How to get less rows per block.

>
> PCTFREE is a very handy tool in this regard. When you are confronted
> with Steve Adam's evidence that you do NOT have a free choice in the
> matter of block size, and are accordingly constrained to pick an
> enormous block size, you can use PCTFREE to deliberately 'waste' space
> at the top of each block, thereby getting back to something more
> 'reasonable' as far as contention issues are concerned.
>

Yup. Here we all know that. But many reading the Oracle mag don't. That's where that info should have been, in the article. It's always the same thing with the Oracle mag: they tell people about all the good stuff, but fail to explain how to achieve or measure or implement it. Another good example is the good old "increase the size of the shared SQL area". Never mind that this is usually a side symptom of about 500 other possible problems. What the heck, memory is cheap!

Not surprised about the very low level of knowledge out there... Crap, even the ones that are supposed to know have problems all over the place! I had recently an ex-Oracle support guy tell me to reserve a *huge* redo space for an import, because "inserts use up lots of redo". Had to introduce him to our little talk here a while ago, pronto! To his credit: he understood, when he saw the dumps and the results.

And many others. It's surprising how many myths survive out there, even nowadays. Very surprising. You know first hand about the good old "indexes in different disk than tables". So many others...

The last one I saw was a well known consultancy company selling the customer on this you-beaut monitoring tool with all sorts of razamatazz goodies blinking on the screen every 5 seconds (God only knows how much CPU that uses up...) and then "recommending" the customer goes to RULE! Which basically stuffed up any possibility of using parallel query in that site, although they badly need it!
Oh well, they get what they pay for, I suppose...

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

Received on Sat Feb 08 2003 - 08:37:59 CST