| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Performance Metrics
Lou,
What business are you in?
Find out which business processes are essential to your business, which are opportunities for profit if done faster, and any service level agreements with customers that cost your money if transaction completion is slower than some rate.
Design a dummy transaction that can be factored out of the real results or reversed for each important business function. Usually this can be done without custom programming, but you need to get sign off from whoever controls your Sarbox (Anderson bankruptcy re-employment act) policies. You also need to make sure that your dummy transaction cannot trigger a business event. For example, if you code up an order entry dummy transaction, make sure that the withdrawal from inventory does not trigger a re-order event, and make sure you stop short of actually generating the paperwork to schedule the manufacture of something to be delivered to your office.
The dummy transactions should be light-weight so that you do not materially degrade performance during peak load. Design switches to turn off each dummy transaction so you can prove that your dummy transaction alone is not material in load (or in the alternative find out that you designed a problem transaction). Also Design a master switch to turn off all dummy transactions. This is convenient for when everything going to hell in a hand cart, you've sampled enough during the crisis, and you want to absolutely rule out the dummy transactions from consideration as the cause of the problem. This is useful even if you know to a scientific fact that the dummy transactions cannot be part of the problem.
Measure pretty much all the time and log the results so you can tell when "the system is slow" from the perspective of business users. Most especially, as business grows over time and transactions overall increase in rate, you might eventually reach a point where your dummy transactions are chronically slower. That is a good time to inspect your capacity planning process for a review if you don't already have upgrades scheduled. A good side check is rate of redo log generation, but remember to factor out any special maintenance events as outliers. Also track system level statistics such as cpu utilization, disk(farm) saturation, network saturation, controller load, etc. A correlation of these numbers against the rates of your dummy transactions can be very useful in predicting future degradation.
Also find a way to count user transactions per hour or per day by some useful category that represents the business. Once you get enough points to feed into a least squares analysis for reasonably confident projections, this can also inform your capacity planning process. (Don't bother printing the results unless you also calculate a confidence range.)
Make a projection how long it would take you to be back in operation at an alternate site if everything goes perfectly in the transition. State that is a best case analysis in your report and significant risk factors in the plan.
Make a projection how long it would take to do a local recovery if something goes so bad you have to do a full restore. Make a projection how long it would take to do a local recovery if you lose an entire storage array.
There is more, but that should put you in good stead. None of this has anything at all to do with performance tuning or repairing a bad current process (although there is a chance you might identify a bad process if a dummy transaction you would presume is for a trivial amount of work takes forever.) If your management is asking the question for respond to some fad of "these numbers are good" then this won't help you much. But if your management is trying to get a handle on the system time requirements to process business flows, you will put them in a position to make good decisions about how to improve the business. One of those decisions will likely be to justly reward you for taking a vague question and giving them a meaningful answer that causes the business to make more money.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Lou Avrami
Sent: Friday, October 28, 2005 3:56 PM
To: oracle-l_at_freelists.org
Subject: Performance Metrics
Hello all,
Upper management has just ask my group to provide performance metrics for our database servers and databases. Even after a couple of conversations we're not quite sure what they mean by "performance metrics", and I'm sure they aren't quite sure what they mean, either. ;)
We could give them Statspack report output, but that probably would be too much information.
If anyone out there has any ideas on what kind of (very) high-level Oracle database metrics might be appropriate, it would be very helpful.
Thanks,
Lou Avrami
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Oct 31 2005 - 07:23:57 CST
 |
 |