The BEQ (or BEQueath) protocol adapter is only usable within the server, not
outside and is actually the best to use when you can. TCP/IP is the most often
used protocol outside of a server and in a client/server configuration. Setting
TDU and SDU to something other than 2K (the default) can in some instances help,
but do not expect it to be a silver bullet. What they actually stand for is the
amount of data that SQL*Net will pass/receive for the underlying TCP/IP layer at
a time. If you set it to a very large value it may well exceed the native size
of the OS's TCP/IP packet which will cause more delay. Nor is tcp.nodelay a
silver bullet since the real delay here is inside the operating system and
network your using. A simple thing like two people using Instant Messenger can
mess this up to no end. If you've got someone on your network who loves
streaming audio and/or video your in trouble. Having a good network engineer is
the best solution. Ours has established virtual LANs or VLANs inside the
company. It has helped immensely since it isolates the hogs from the rest of
the world. As for limiting duhvelopers, well one can try. I'll send you a case
of baseball bats, they may help but don't count on it.
In a particle point of view, I'm on a 100MB switched VLAN'd network at work.
Selecting 100000 rows of data from our PeopleSoft database takes around 45
seconds (the server is an HP 9000/N4000 with 8 processors and Oracle 8.1.6).
Conversely doing the same select from my private database server at home ( 10MB
with a hub ) took 20 seconds ( Pentium II 100MHZ running Linux and 8.0.5).
TDU/SDU were at the default in both environments, the amount of data transferred
was the same, but at home the network consists of 4 PC's and it was quite. I
also tried this while my wife was happily browsing the web which goes over the
same home network since one PC on the net is a proxy server. I did see an
increase in the amount of time it took to 60 seconds. Therefore the amount of
network traffic and bandwidth available more are significant than the settings
of SDU/TDU. BTW: Always keep both is sync. I had one larger than the other
once, caused all kinds of delays.
Dick Goulet
____________________Reply Separator____________________
Author: John Kanagaraj <[EMAIL PROTECTED]>
Date: 8/20/2002 12:18 PM
Anjo,
On a related topic: I always wanted to know what the 'SQL*Net break/reset to
client' (or to dblink) means... There isn't much out there :(
John Kanagaraj
-----Original Message-----
Sent: Tuesday, August 20, 2002 2:13 AM
To: Multiple recipients of list ORACLE-L
SQL*Net ships data (in TCP and BEQ) in packets of 2K (default TDU and SDU
size, with a few exceptions on that for some platforms and protocol
adapters). If you select to the client many large columns or multiple rows
(array fetch), this 2K is filled up quickly and SQL*net will send the next
2K to the client until the full packet has been sent.
Now what can be done about this ? There are two basic solutions:
1) do we need that amount of data ? for example, programmers writing select
* from <tab> and the * translates to many (large) columns. Solution here is
to select
the columns that you need. Another problem could be that the array fetch
size is set to large and that you are fetching too many rows (like 100 but
you need only 10). Solution reduce the array fetch size.
2) If we need the amount of data we should make it cheaper to get the data.
So a larger TDU and SDU might help but could move the problem from problem
from the SQL*Net layer to the underlying protocol (TCP/IP in this case and
ethernet ?). TDU should be adopted to the underlying transport layer (fibre
4500 or so). The most common problem is that before each send there is a
delay (Naggle algorithme) and that can be fixed with tcp.nodealy = true on
both the server (that should be enough in this case) and the client.
Now there are some issues in the SQL*net with SDU and TDU and tcp.nodelay
depending on version. There were a lot of issues in 7.3 (like were to set
SDU and TDU size and the location of the protocol.ini/ora file for setting
tcp.nodelay =true). Also make sure that the client software uses the SQL*net
layer that is 7.3 based and not 7.0/7.1 which is very common.
Anjo.
----- Original Message -----
To: Multiple <mailto:[EMAIL PROTECTED]> recipients of list ORACLE-L
Sent: Tuesday, August 20, 2002 4:08 AM
Hi,
I am tuning a system at a client site and notice lots of waits for SQL*Net
<http://213.46.46.10/cgi-bin/yappweb206#SQL*Net more data to client#SQL*Net
more data to client> more data to client (97%) for a fraction
of the CPU consumed by the system.
I know this is not to be characterized as an idle wait event and can yield
better performance if we increase
the packet size.
The database is Oracle 7.3.4 (SQL Net 2.3). What effect will increasing TDU
and SDU have
on this wait to increase packet size.
It seems that if we can reduce this wait then we can save lots of time (I
Think).
Will using BEQ protocol help at all.
Regards
Suhen
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: John Kanagaraj
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
