RE: LOB Operation and SQL*Net Message From Client and cursor #0
Date: Wed, 01 May 2013 06:45:43 -0500
Message-id: <000701ce4661$69a7cde0$3cf769a0$_at_net>
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
elkinsl_at_verizon.net
Cell: 214.695.8605
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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.
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 01 2013 - 13:45:43 CEST