Re: LMT advice

From: Noons <wizofoz2k_at_yahoo.com.au>
Date: Sat, 27 Sep 2003 15:12:42 +1000
Message-ID: <3f751c81$0$2471$afc38c87@news.optusnet.com.au>

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:3f74dd7c$0$6610$afc38c87_at_news.optusnet.com.au...

>

> None whatsoever, except that you have to decide on what the uniform size
> should be. I tend to recommend 64K, 1M, 8M and 64M, but 'How to stop
> worrying about fragmentation and start living', or whatever that Metalink
> whitepaper was called, decided some other sizes would be good. Who can tell
> what sizes are good and what aren't?

So tell me: what is the difference between having to decide what uniform size we use for ASSM and having to decide on a uniform size for a non-ASSM LMT? Sounds to me like 6 of one, half a dozen of the other?

> and the more we can get away from worrying about things like that, and
> concentrate on the stuff that counts, such as crappy SQL or chronically
> over-normalised design, the better for everyone, I think.

10000% in agreement. When the gain from fixing one bad SQL can be in orders of magnitude of less CPU usage, it is really hard to explain why do we have to spend time pulling the last 10% of CPU out of a bitmap allocation. Quite frankly, ASSM or non-ASSM, to me uniform LMT allocation is where I've stopped worrying. The gains from going into more detail there are very relative, to say the least.

> PCT_INCREASE will take an extremely long time to go away!!). But lots of
> testing here, anyway, indicates that as automation goes, autoallocate's
> pretty darned sexy.

Nothing wrong with testing. That is why the information coming from people like you who do it almost as a full time job is so valuable and important. We must not forget that the average Joe DBA out there just does NOT have the time to test to this extent. Hence the importance of publishing these results.

> But maybe I must just get out more!

If that means you stop testing, please don't! :)

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

Received on Sat Sep 27 2003 - 00:12:42 CDT