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@xxxxxxx> > 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@xxxxxxxxx> > > To: "Egor Starostin" <egorst@xxxxxxxxx> > > Cc: <sat0789@xxxxxxxxxxx>; <oracle-l@xxxxxxxxxxxxx> > > 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@xxxxxxxxx> > > 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 > > -- > > //www.freelists.org/webpage/oracle-l > > > > > > -- > > //www.freelists.org/webpage/oracle-l > > -- //www.freelists.org/webpage/oracle-l