It's 800 sec for 5617 exec/fetch calls. It looks like it's a sql inside a
cursor loop or stored proc that gets called from some app.
If you are unhappy, try to get rid of the cursor logic and get everything
done in one sql call.
Waleed
-Original Message-
Sent: Tuesday, October 28,
Have you run SQLTRACE on this query?
The detail in the trace file will show
where the cpu is being consumed.
There is insufficient data in the summary
to reach any conclusion.
Jared
On Mon, 2003-10-27 at 21:24, Muqthar Ahmed wrote:
Hi,
Execution plan looks good but the query is consuming
Jared,
The output is from TKPROF.
Muqthar
-Original Message-
Sent: Tuesday, October 28, 2003 9:24 AM
To: Multiple recipients of list ORACLE-L
Have you run SQLTRACE on this query?
The detail in the trace file will show
where the cpu is being consumed.
There is insufficient data in
just in case, if you have specified explain= on the command line to generate tkprof
summary, remove it and just do
tkprof filename ...
which version of oracle?
Raj
Rajendra dot Jamadagni at nospamespn dot com
All
check out asktom. its up for today. if you use an 8i tkprof on a 9i trace file, you
get bad cpu results.
are you doing that?
From: Muqthar Ahmed [EMAIL PROTECTED]
Date: 2003/10/28 Tue AM 11:04:24 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Execution Plan
Hi,
The developer was executing the SQL statement in the loop in procedure. After
re-writing the code, now the performance is good.
Thanks
Muqthar Ahmed
-Original Message-
Sent: Tuesday, October 28, 2003 8:09 AM
To: Multiple recipients of list ORACLE-L
It's 800 sec for 5617
]
cc:
Subject:RE: Execution Plan is good but HIGH CPU
Jared,
The output is from TKPROF.
Muqthar
-Original Message-
Sent: Tuesday, October 28, 2003 9:24 AM
To: Multiple recipients of list ORACLE-L
Have you run SQLTRACE on this query?
The detail in the trace file will show
Hi,
I guess you are just using RBO and did not analyze your table. Try analyze it and
run it again.
You nested loop maybe is inefficient, as it generate a lot of buffer_gets.Maybe
you can consider using hash_join instead of nested loop.
If you still plan to use nested loop, consider
