RE: LOB Operation and SQL*Net Message From Client and cursor #0

  • From: "Larry Elkins" <elkinsl@xxxxxxxxxxx>
  • To: "'D'Hooge Freek'" <Freek.DHooge@xxxxxxxxx>
  • Date: Tue, 30 Apr 2013 17:19:06 -0500

What we would see is fetch calls for the SQL statement driving the elapsed time 
match doing array fetches, seen in the summary of
fetch calls as well as looking at "r=" on the FETCH call in the raw trace. Then 
the sql*net message from client on CURSOR #0, which
tied back to the LOB operations when doing the 10051 trace, would be mixed in 
between those fetch calls. This I believe is what you
are describing. I'm assuming the lob locator being returned then going back and 
getting the LOB data.

Our first step was the 10046. And yeah, our thought when so little time in the 
DB was ok, how much of this is network time, and how
much is client think time? And that's why one of the other people dropped opnet 
on the process, which should be able to break that
out, how much time in the client, on the middle ties, how much on the network, 
etc.

Larry G. Elkins
elkinsl@xxxxxxxxxxx
Cell: 214.695.8605


> -----Original Message-----
> From: D'Hooge Freek [mailto:Freek.DHooge@xxxxxxxxx]
> Sent: Tuesday, April 30, 2013 2:19 PM
> To: elkinsl@xxxxxxxxxxx
> Cc: 'Oracle-L'
> Subject: Re: LOB Operation and SQL*Net Message From Client and cursor #0
> 
> Larry,
> 
> sql*net from client can also point to processing or think time on the client 
> / application server and
> not only time spend on the network.
> 
> One of the problems I have seen with lobs is that they are always returned 
> row by row instead of
> returning an array of them causing the network latency to play a very 
> important role. Also I have
> noticed that some connection libraries (odbc if I recall correctly) will 
> first retrieve the length of
> the lob before retrieving the actual data (adding another roundtrip to it).
> 
> 
> regards,
> 
> --
> Freek D'Hooge
> Uptime

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


Other related posts: