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

From: D'Hooge Freek <Freek.DHooge_at_uptime.be>
Date: Wed, 1 May 2013 09:58:33 +0200
Message-ID: <1367395113.3107.66.camel_at_dhoogfr-lpt1>

Larry,
As you stated that the lob is rather small, could you check if it is kept inline?

regards,

-- 
Freek D'Hooge
Uptime
Oracle Database Administrator
email: freek.dhooge_at_uptime.be
tel +32(03) 451 23 82
http://www.uptime.be
disclaimer: www.uptime.be/disclaimer.html




On wo, 2013-05-01 at 00:19 +0200, Larry Elkins wrote:


> 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

> 

> 


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

Received on Wed May 01 2013 - 09:58:33 CEST