Message-ID: <F001.0045854E.20020505114819@fatcity.com>
Date: Sun, 05 May 2002 11:48:19 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
Sender: root@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: Stephane Faroult <sfaroult@oriole.com>
Subject: Re: Response time analysis and TKPROF
Organization: Fat City Network Services, San Diego, California
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anjo Kolk wrote:
> 
> Stephane.
> 
> The SQL statement is the right level, believe it or not. Basically the most
> expensive SQL statements (resource wise) will float to the top that way.
> 
> Anji,
> 

I disagree, with a strong feeling of not talking about the same thing. 
My favorite method for finding the most expensive SQL statements is
rather to check buffer gets at regular intervals, but here of course is
a question of personal taste. But I meet more and more (business)
processes in which, without being top-notch, SQL statements do not look
terribly bad. Rewrite everything, and it roars. I am not sure that
digging deep in this case inside trace files is the most effective.
Having a talk round the coffee-machine with end-users also helps. And
you always have that terrible SQL statement which runs at 2 am and about
which nobody cares as long as the maintenance window is large enough.
What I question is the need to abuse queue theory when, let's put it
clearly, the problem is awful code written by beginners under the
leadership of people too often unable to reread what has been written by
their 'subordinates'. And I have strong doubts about how easily you will
'sell' it to a management who better understands that a faster processor
(or an additional processor) may make things run faster - even if we all
know that it is far from being always true. How much simpler for a
'decision taker' than purchasing days of consulting for a result which
may, and usually will, be much more efficient, but for which quantifying
(even wrongly) results is much more delicate.

End of rant ;-).

-- 
Regards,

Stephane Faroult
Oriole Software
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephane Faroult
  INET: sfaroult@oriole.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).