| 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: Capacity Planner from OEM VS Statspack
Interesting problem. Perhaps if you broke out the timing in the event calls
with a min and a max you would see a skew the average time hides? I assume
it's not the number of calls then, but the total time that's much longer
when this happens?
I have an interval resource profile perl script that I've just made available on appsdba.com that you could try running the trace file against if you're interested.
Andy Rivenes
arivenes_at_llnl.gov
At 03:51 PM 2/2/2004 -0800, MacGregor, Ian A. wrote:
>Andy, you have parroted my warnings about running the trace immediately
>vs. tracing it when the job normally runs. Well at least we agree on
>that. Let's take another look at the profile
>
>Call Duration Calls Duration/Call
>------------------------------------------------------------------------------
>direct path write 95.28s 81.1% 5707 0.02s
>direct path read 21.47s 18.3% 7632 0.00s
>SQL*Net message from client 0.59s 0.5% 4 0.15s
>db file scattered read 0.17s 0.1% 652 0.00s
>SQL*Net message to client 0.00s 0.0% 4 0.00s
>db file sequential read 0.00s 0.0% 1 0.00s
>
>Total cpu time: 30.5 seconds
>
>Again. I know direct path I/O's are the major wait, and the actual trace
>will tell me the file in question. But even a 10046 trace doesn't tell me
>why it was happening. In this case it was being caused by another
>instance which was beating up the disk which held the file.
>
>Oracle has methods of lowering a session's priority if it is CPU
>intensive. I'd like it to be able to do the same for I/O intensive
>operations as well.
>
>Ian
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon Feb 02 2004 - 18:34:06 CST
 |
 |