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

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: "'Oracle-L'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 1 May 2013 09:55:22 -0400

We haven't yet talked about the client capacities.

Can you place a client containing the standard vendor code as close as
possible in network terms to the dbserver?

Can you also try a client with more:
1) cpu speed
2) faster video/graphics
3)memory

A "hot rod" version of the client machine located in the database server
room is an excellent control for localizing problems like this.

A standard version of the client machine located in the database server room
is an excellent control for determining how much of the problem is a network
issue. Please notice that bad use of the network (excessive line
turn-arounds, for example) may not show up in network monitoring tools as
bad network performance, and indeed it is not bad network performance.

mwf

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Larry Elkins
Sent: Wednesday, May 01, 2013 7:46 AM
To: mwf@xxxxxxxx; 'Oracle-L'
Subject: RE: LOB Operation and SQL*Net Message From Client and cursor #0

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@xxxxxxxxxxx
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.

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


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


Other related posts: