RE: [Fwd: Re: 10046 trace - unaccounted for time] - long raw

Does anyone know if the below mentioned anomaly of LOB data operations showing as unaccounted also applies to LONG RAWs? I'm ending up with a trace that has a lot of unaccounted for time and it's on tables with LONG RAW datatypes.

I suspect that's what's happening but wanted to confirm it.

Thanks,

Jay Miller

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tanel Poder Sent: Friday, August 08, 2008 7:04 AM
To: kmoore_at_zephyrus.com
Cc: 'oracle-l'
Subject: RE: [Fwd: Re: 10046 trace - unaccounted for time]

The reason why you didn't see any cursor using that CPU time could be due how some Oracle calls are handled.

For example when you run "describe xyz" in sqlplus, that describe command does not go through normal cursor parse/execute/fetch cycle. In fact there is no library cache cursor associated with this call at all (describe calls opidsc directly in kernel).

The same goes with LOB data operations. The INSERT INTO ... statement itself is parsed and a shared cursor is generated for it, but the lob data load operations will bypass this cursor execution mechanism and call the data loading functions directly. The direct load interface probably behaves the same way.

In summary - as these operations bypass normal cursor execution, they also don't hit any cursor instrumentation codepath. However if these operations hit some waits, then these are instrumented and reported as waits for CURSOR #0 (which is kind of pseudocursor).

Some relevant info is here:

http://vsadilovskiy.wordpress.com/2007/10/29/trace-and-statspack-lob-1/

--
Regards,
Tanel Poder
http://blog.tanelpoder.com
 



> -----Original Message-----

> From: oracle-l-bounce_at_freelists.org

> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Keith Moore

> Sent: Friday, August 08, 2008 02:50

> To: kmoore_at_zephyrus.com

> Cc: oracle-l

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

> 

> Can anyone tell me whether moving the blob to a different tablespace 

> will cause the index to be rebuilt. I know the index moves so it seems




> like it would need to be rebuilt but just wanted to confirm.

> 

> Keith

> 

> > Thanks. We have confirmed it is some type of LOB index corruption.

> >

> > Insert to BLOB stored inline works fine.

> > Insert to BLOB stored out of line (one row, 5MB blob) takes

> 4 minutes

> > Insert to BLOB stored out of line (new copy of table) takes

> 0.125 seconds.

> >

> > We are now rebuilding table.

> >

> > Thanks to everyone for their help.

> >

> > Keith

> >

> 

> 

> --

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

> 

> 


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


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