Re: [Fwd: Re: 10046 trace - unaccounted for time]

You are right. It doesn't make much sense. The file and blocks you asked about are in the LOBINDEX segment in the LOB tablespace. That doesn't seem to match the CURSOR # for the wait.

See my other post. We are suspecting the LOB index is corrupt but have no evidence of that other than it is 8 times bigger than before the archive and after it is accessed no further real work happens. Just 100 million plus consistent gets.

I can send you the trace file but I'm not sure that is productive at this point.

Keith

> That doesn't make much sense.
>
> Insert statment is inserting with a lob size of 3880 bytes and returning
> that column of 3880 bytes.
> For cursor #11:
> PARSE has timestamp of tim=5188376807523 and EXC has timestamp of
> tim=5188376817822.
> difference is 10291 micros, which is close enough to 10076 micros
> printed in EXEC stats.
>
> Followed by waits for cursor #12, which is not an insert statement. But,
> wait is for 'sql*Net more data from client' which
> is a typical wait if there is huge amount of data being passed from the
> client.
>
> So sequence of waits are: Almost looks like huge amount of data is
> passed from the client. Also, it is possible that due to rounding
> errors, time is not properly accounted in tkprof.
>
> 2 sqlnet more data
> 1 lob write
> 6 more sqlnet data from client..
> 1 lob read
> 8 more sqlnet data from client..
> 1 single block read p1=232 p2=113031 p3=1
> 8 more sqlnet data from client..
> 1 single block read p1=232 p2=113032 p3=1
> 8 more sqlnet data from client..
> 1 latch free. p2=98
>
> Keith,
> Can you please find what block is file 232, block 113031 and 113032 ?
> What version of Oracle is this? Also, if you could send me raw trace
> file, that will be great..
>
> Cheers
> Riyaj
> The Pythian group : www.pythian.com
> blog: http://orainternals.wordpress.com
>

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