With 8.1.6 stats pack comes with the database. So you do have it.
--
Niall Litchfield
Oracle DBA
Audit Commission UK
"ZS" <zs_nospam_at_yahoo.com> wrote in message
news:3B830D01.A1ED6BEE_at_yahoo.com...
> 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 Wed Aug 22 2001 - 05:02:47 CDT
