Re: 3GB RAM usage by Oracle

From: Richard Foote <richard.foote_at_bigpond.nospam.com>
Date: Sun, 29 Aug 2004 10:54:01 GMT
Message-ID: <dBiYc.12212$D7.3104@news-server.bigpond.net.au>

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:41313b1c$0$22855$afc38c87_at_news.optusnet.com.au...
> Don Burleson wrote:
>
> >> Most databases have performance problems for very simple reasons such
> >> as . . . failure to build appropriate indexes, failure to gather
> >> appropriate statistics.
> >
>
> [snip. particularly the dreadful cursor_sharing advice]
>
> >
> > Just last week I had a client who was having a huge CPU bottleneck,
> > and the root cause was excessive parsing and REALLY bad SQL.
>
> You are cheating, Don. How do you know that the cause was excessive
parsing
> and really bad SQL? Because you looked and made sure??
>

Hi Howard,

Do you really think he "looked and made sure" ?

A few points I would make include:

Do you really think Don can upgrade CPUs in 15 mins. 15 mins to order/purchase, have delivered, installed, tested, rebooted ... Somehow I think not.
Do you really think Don diagnosed and identified *2000* "REALLY bad SQL" (Don's quote) statements ? Somehow I think not ...
Do you really think that a CPU upgrade can magically convert a system with dire and urgent performance problems due to *2000* "REALLY bad SQL" statements into a lean, mean fighting machine ? Somehow I think not ...
Do you really think a *single* "REALLY bad SQL" statement that for example performs an unnecessary FTS and reads say 100,000 blocks unnecessarily (rather than the 4 blocks required) will magically run efficiently and effectively with a faster CPU ? Then multiply by *2000*. Somehow I think not ...

Don's advice in this respect is appalling and not fairy tales can cast Method "D" in better light !!

BTW, still searching, searching in my quest to find all these "not uncommon" 30G buffer cache sites ...

Cheers

Richard Received on Sun Aug 29 2004 - 05:54:01 CDT