Re: TKPROF output -- high current gets for INSERT

Do a quick test. Create a small copy of the table, with appropriate FKs. Start tracing, insert some rows, end tracing.

Or do the following query before and after you insert:

select c.value, nc.name
from v$mystat c, v$statname nc
where nc.statistic# = c.statistic#
and nc.name in ('db block gets','consistent gets') order by nc.name;

Drop the FKs and repeat the test.

Report results to list. :-)

--Terry

> I really would like to know that part..Fk is still in force.
> """""Are there current gets associated with checking the referential
> integrity
> (index is unusable but FK still in force)?"""""
>
>
> On Thu, 30 Dec 2004 13:56:45 -0800, "Terry Sutton" <terrysutton_at_usa.net>
> said:
> > The phrase "Elapsed times include waiting on following events:" comes
> > from a
> > tkprof output, where the wait times are expressed in seconds (as opposed
> > to
> > v$session_wait where they're in centiseconds (or micro in
> > time_waited_micro
> > in 9i)).
> >
> > Are there current gets associated with checking the referential
integrity
> > (index is unusable but FK still in force)?
> >
> > --Terry
> >
> > ----- Original Message -----
> > From: "stephen booth" <stephenbooth.uk_at_gmail.com>
> > To: "Egor Starostin" <egorst_at_gmail.com>
> > Cc: <sat0789_at_fastmail.fm>; <oracle-l_at_freelists.org>
> > Sent: Thursday, December 30, 2004 12:21 PM
> > Subject: Re: TKPROF output -- high current gets for INSERT
> >
> >
> > On Fri, 31 Dec 2004 02:07:14 +0600, Egor Starostin <egorst_at_gmail.com>
> > wrote:
> > > It's not a 12 seconds it's a 1192 seconds, I think.
> > > And it doesn't look like 'collection error' since the max.wait is 2.8
> > seconds
> > > Probably the problem is on client's side, not on the server. Server
> > > spent 23 seconds of it's CPU time and waited 1192 seconds for client's
> > > commands.
> >
> > I checked the docs, according them that's centiseconds (100ths of a
> > second) 1192cs is 11.92s, close enought to 12 for government work.
> >
> > >
> > > > Having to get nearly 20 blocks per row does seem a bit excessive.
> > > Maybe a _little_ bit excessive.
> > >
> >
> > Depends on the row size vs blocksize I suppose. If the average row
> > size was 40k and block size was 2k that would explain the blocks per
> > row. I'd hope that the poster would have said if that was a
> > possibility.
> >
> > Stephen
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> > --
> > http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l