Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Capacity Planner from OEM VS Statspack

RE: Capacity Planner from OEM VS Statspack

From: Andy Rivenes <>
Date: Mon, 02 Feb 2004 16:34:06 -0800
Message-Id: <>

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 that you could try running the trace file against if you're interested.

Andy Rivenes

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.

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Mon Feb 02 2004 - 18:34:06 CST

Original text of this message