RE: LOB Operation and SQL*Net Message From Client and cursor #0
Date: Tue, 30 Apr 2013 17:19:06 -0500
Message-id: <002801ce45f0$baddaac0$30990040$_at_net>
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_at_verizon.net
Cell: 214.695.8605
> -----Original Message-----
> From: D'Hooge Freek [mailto:Freek.DHooge_at_uptime.be]
> Sent: Tuesday, April 30, 2013 2:19 PM
> To: elkinsl_at_verizon.net
> 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
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 01 2013 - 00:19:06 CEST