| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re:RE: how to reduce SQL*Net more data to client wait event
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 <john.kanagaraj_at_hds.com> 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:
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.
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: john.kanagaraj_at_hds.com
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: ListGuru_at_fatcity.com (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).
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: ListGuru_at_fatcity.com (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). Received on Tue Aug 20 2002 - 17:33:24 CDT
 |
 |