Re: How to find the 10 worst performing SQL statements?

Don't understand this point? why its not worth to turn the sql-trace? I thought sql-trace is the one to help you identifying the statements, in case you don't have statspack!. ZS

Ford wrote:

> Does'nt seem much point in turning on sql-trace till you've identified
> the statements - look in v$sqlarea for those with the most
> buffer_gets/execute (cpu in effect), physical_reads/execute and those
> that have been executed a lot - pretty much what statspack does - then
> trace those statements. 9i has the cpu time as well in v$sqlarea.
>
> enzoweb_at_hotmail.com (Andy) wrote in message news:<8d4033cd.0108211451.43a38283_at_posting.google.com>...
> > I have been asked to find out the 10 worst performing SQL statements
> > on a V816 database on Solaris.
> >
> > The only way I can think of doing it is to turn SQL_TRACE on
> > (TIMED_STATS are already on), and run tkprofs against the resulting
> > trace files at the end of each day. Then grep the results to pick out
> > the stat I want and filter through them.
> >
> > Without installing Stats pack, is this the best way?
> >
> > Also, what should I look for - elapsed time, CPU time, or I/O?
> >
> > TIA,
> > Andy
Received on Tue Aug 21 2001 - 20:38:10 CDT