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

  • From: "Larry Elkins" <elkinsl@xxxxxxxxxxx>
  • To: <mwf@xxxxxxxx>, "'Oracle-L'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 01 May 2013 06:45:43 -0500

With this being vendor code, probably pretty tough to get the client changed 
the way you describe. The opnet tool the other folks
are using is supposed to be able to measure client processing time versus time 
on the network, etc. They are showing some client
time, but not a whole lot. In other words, and I don't have the numbers in 
front of me, let's say they are showing 10% client think
time, <1% actually on the network, they are then attributing the remaining time 
to the DB, which we don't see in the DB. Will do
some more tests today.

Larry G. Elkins
Cell: 214.695.8605

> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
> Behalf Of Mark W.
> Farnham
> Sent: Wednesday, May 01, 2013 6:20 AM
> To: 'Oracle-L'
> Subject: RE: LOB Operation and SQL*Net Message From Client and cursor #0
> IF a version of the real remote client can be configured such that it doesn't 
> bother with rendering
> the LOB in any way, that should help a lot in determining where 90% of the 
> current service time
> resides.
> IF, indeed, it is in the rendering and processing on the client, then both 
> the network monitor and the
> dbtime monitors are probably close enough to correct and what needs to be 
> fixed is the client
> rendering (not the network or the database).
> Sometimes, when the network guys say "It's not ME!" and the database guys say 
> "It's not ME!" and the
> storage guys say "It's not ME!" they are all correct and the problem really 
> is in the client
> processing software. (By the way, this can also include client "think time" 
> as that looks about the
> same to network and db guys in a process progress diagram.)
> Good luck Larry. You seem to be taking reasonable stepwise progress toward 
> identifying the problem.


Other related posts: