Re: how to reduce SQL*Net more data to client wait event

[Tim Gorman]

"SQL*Net more data to client" (as opposed to "from client") seems to indicate that flow is from server to client, which doesn't seem appropriate for SQL statements... ----- Original Message ----- From: Johnson, Michael To: '[EMAIL PROTECTED]' ; 'Tim Gorman' Sent: Wednesday, August 21, 2002 11:59 AM Subject: RE: how to reduce SQL*Net more data to client wait event Tim,   more specifically could large SQL have been passed across the net ?   Stored procedures could help here.   FWIW.   Mike -----Original Message----- From: Tim Gorman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 12:03 AM To: Multiple recipients of list ORACLE-L Subject: Re: how to reduce SQL*Net more data to client wait event Depending on the application, couldn't these large pauses be performance problems in the client program?  Not a server tuning issue nor a SQL*Net tuning issue at all?  For example, if the client program was pausing a long time between FETCH commands, processing previously fetched data?  Or would that just be accounted for under "SQL*Net message from client" events? ----- Original Message ----- From: Suhen Pather To: Multiple recipients of list ORACLE-L Sent: Monday, August 19, 2002 8:08 PM Subject: how to reduce SQL*Net more data to client wait event Hi,   I am tuning a system at a client site and notice lots of waits for SQL*Net 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