Re: HELP - frames/packets being resent (duplicated) for Oracle sql*net connection.

In article <3962777f.3616209_at_newshost.interact.net.au>,   granta_at_nospam.student.canberra.edu.au (Fuzzy) wrote:
> On Tue, 4 Jul 2000 15:41:29 +0200, "Sybrand Bakker"
> <postbus_at_sybrandb.demon.nl> wrote:
>
> >As you have severely edited you output, how can we see it is
 identical?
>
> Sorry, I thought the Sniffer output line that said: "Retransmission
> TNS: duplicate of frame 4831" was the give-away there. :-)
>
> >you would have used sqlnet tracing, that would have provided you
 with lots
> >of more insight.
>
> An excellent point ... thanks Sybrand. As you've probably guessed,
> this is coming from an outsourced networking guy, who's answer to the
> question "What does the net8 trace show?" was "net what?".
>
> >Three general remarks
> >- Before the data of any select statement is sent, a description of
 all
> >columns in that statement, including datatypes etc, will be sent to
 the
> >client. (I learned this from studying sqlnet trace output).
>
> Yep, know this. We'll use trace level 16 to see what's actually in
> the packets.
>
> >- If a cursor is closed by the client and re-opened by the client
 all data
> >is resent, whether it has changed or not. I noticed this to be a
 problem in
> >an application with numerous listboxes, comboboxes and the like on
 screen,
> >all the underlying cursors were closed as soon as that control lost
 focus
>
> We know the app doesn't do this - we've been burnt by stupid cursor
> handling before.
>
> >- ODBC is about the most inefficient mechanism to use in
 communication with
> >an Oracle database.
>
> But until we've done our OLEDB work, it's the only STANDARD way to
> talk to Oracle (don't get me started on the proprietary coding stuff
> :-) PL/SQL and OCI are nice if you never want to port your app to
> other db's).
>
> >If you really want to track the cause (and personally, as it's only
 20
> >percent and some duplication is inevitable, so I wouldn't bother),
 you'll
> >need to add or change
> >trace_level_server = 16 in your sqlnet.ora on the server.
> >That will automatically trace *all* sqlnet connections.
>
> Will do. 20% is significant in this instance, as the client is trying
> to run 20+ people with this product, and file sharing, mail, web, etc
> over one 32K frame relay that's 4000km (~2500 miles) long. I offered
> to give them $100 to by two decent modems ... and only got poisonous
> looks in return :-)
>
> Thanks again.
>
> Ciao
> Fuzzy
> #;-)
>

Two additional remarks
- We started to investigate the problems I outlined below, because our 128k connection from Hoofddorp (Netherlands) to Exton (Pennsylvania) was continually used to it´s full potential, with similar numbers of users.
So I guess your customer will not get away with 32k bandwith, but I understand that´s your analysis too.
- Secondly, you can ´tweak´ sqlnet by changing the S(ystem)D(ata)U(nit) and the T(ransmission)D(ata)U(nit). Both are 2048 by default, which is awful in relation to a MTU of 1510 on most Windoze systems. You need to set those parameters BOTH in listener.ora on the server AND tnsnames.ora on the client as the last elements of a service definition, before the concluding ).
Don´t throw away your sniffer yet and use that in conjunction with the sqlnet trace. The sqlnet trace will dump the actual packets. You will probably notice the packages are much smaller than you expect.

Hth,

>

--
Sybrand Bakker, Oracle DBA

All standard disclaimers apply
------------------------------------------------------------------------


Sent via Deja.com http://www.deja.com/
Before you buy.