RE: Good Performance

  • From: "Powell, Mark D" <mark.powell@xxxxxxx>
  • To: Oracle-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 20 Apr 2005 14:21:55 -0400

The only real performance measure is customer satisfaction.  Either the
customer is satisfied with the overall application response time or they are
not. 

HTH -- Mark D Powell --


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Wiegand, Jeff
Sent: Wednesday, April 20, 2005 1:58 PM
To: Oracle-L
Subject: Good Performance 

Could someone give me some "benchmarks" defining good performance?

Our management comes from small shop, SQL Server world. I was the first
Oracle resource here, about a year and a half ago. We have a web-based
platform using RAC, BEA and IFS ...

There were some performance issues about three months ago and after many
battles I convinced management to add spindles ... Things improved until a
major upgrade of the app. After the upgrade things tanked. It's diffucult to
run legitimate tests in our LOD environment (long story).
Two days later myself and the architect for the app made some changes, and
things are once again speedy. BUT, we now have consultants coming out of the
woodwork, retained by management. Mutliple companies doing analysis.=20

What do I say when I feel we shouldn't monkey with things. Of course there
is going to be queries to tune. But my question is this:

What is a good benchmark for determining if a query is doing too many buffer
reads, or too many disk reads? Is 10,000 buffer reads considered high, or is
it 1,000,000? Or does it matter if, on the overall, things kick butt.

This is a half hour window during peak usage. Is anything way off?

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.93       Redo NoWait %:
100.00
            Buffer  Hit   %:   98.78    In-memory Sort %:
100.00
            Library Hit   %:   99.86        Soft Parse %:
98.96
         Execute to Parse %:   85.06         Latch Hit %:
99.97
Parse CPU to Parse Elapsd %:   93.68     % Non-Parse CPU:
99.66

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     %
Total
Event                                               Waits    Time (s)
Ela Time
-------------------------------------------- ------------ -----------
--------
CPU time                                                        1,705
41.97
db file sequential read                           223,374       1,123
27.65
global cache cr request                           377,359         776
19.10
log file sync                                      26,171          92
2.27
global cache null to x                             20,304          85
2.10
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l

Other related posts: