RE: cpu time and query column in tkprof output
- From: Martic Zoran <zoran_martic@xxxxxxxxx>
- To: yasbs@xxxxxxxxxxxxxx, cary.millsap@xxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Thu, 3 Feb 2005 02:55:06 -0800 (PST)
Hi Yasin,
These are LATCH stats and not STAT stats.
Latch statistics are very important to predict which
SQL will behave better when running in multiuser
environment, with many processes doing the same or
similar SQL's causing them to wait/lock/block on these
latches.
Stats are showing more about what you needed to
perform and partially on what you spend your pure CPU
time.
Your first SQL can be faster but it is less scalable
and can cause ELAPSED time to be worse if you have
very busy system.
You should test it in real case scenario while having
other things running (ideally the production :)
Regards,
Zoran
--- Yasin Baskan <yasbs@xxxxxxxxxxxxxx> wrote:
> Here are all the stats. Yes the execution plans are
> different. What i am
> trying to do is to re-write the sql for better
> performance. I re-write
> the sql ang get lower number of logical reads, but
> lose in other areas
> as i mentioned.
>
> So, by looking at the following stats and cpu time
> and elapsed time, i
> understand that i should stick with the original sql
> as the new sql
> performs worse.
>
> NAME
> RUN1 RUN2
> DIFF
> --------------------------------------------------
> ---------- ----------
> ----------
> LATCH.job_queue_processes parameter latch
> 1 0
> -1
> LATCH.ktm global data
> 0 1
> 1
> LATCH.ncodef allocation latch
> 1 0
> -1
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
--
//www.freelists.org/webpage/oracle-l
Other related posts:
