Return-Path: Received: from newsfeed.cts.com (newsfeed.cts.com [209.68.248.164]) by naude.co.za (8.11.2/8.11.2) with SMTP id g7LJOY211056 for ; Wed, 21 Aug 2002 15:24:34 -0400 Received: from fatcity.UUCP (uucp@localhost) by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id MAA14839; Wed, 21 Aug 2002 12:21:25 -0700 (PDT) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 004BBB7C; Wed, 21 Aug 2002 12:08:39 -0800 Message-ID: Date: Wed, 21 Aug 2002 12:08:39 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: "Anjo Kolk" Sender: root@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: "Anjo Kolk" Subject: Re: how to reduce SQL*Net more data to client wait event Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman Precedence: bulk Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C24955.F9ADCD00" ------=_NextPart_000_000E_01C24955.F9ADCD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, this is "to client", so it is the result of a query (either to many = columns or too many rows returned). Large SQL statements would result in "from client" during the Parse = phase and if people keep on parsing the same statement, the client side = will keep on sending it to the server. Parse once/execute many .... Anjo. ----- Original Message -----=20 From: Johnson, Michael=20 To: Multiple recipients of list ORACLE-L=20 Sent: Wednesday, August 21, 2002 9:10 PM 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:Tim@SageLogix.com] 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 -----=20 From: Suhen Pather=20 To: Multiple recipients of list ORACLE-L=20 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=20 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=20 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. =20 Regards Suhen =20 ------=_NextPart_000_000E_01C24955.F9ADCD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No,
 
this is "to client", so it is the = result of a query=20 (either to many columns or too many rows returned).
Large SQL statements would result in = "from client"=20 during the Parse phase and if people keep on parsing the same statement, = the=20 client side will keep on sending it to the server. Parse once/execute = many=20 ....
 
Anjo.
----- Original Message -----
From:=20 Johnson, Michael =
Sent: Wednesday, August 21, = 2002 9:10=20 PM
Subject: RE: how to reduce = SQL*Net more=20 data to client wait event

Tim,   more specifically could = large SQL=20 have been passed across
the=20 net ?   Stored procedures could help = here.
 
FWIW.
 
Mike
-----Original Message-----
From: Tim Gorman=20 [mailto:Tim@SageLogix.com]
Sent: Wednesday, August 21, = 2002 12:03=20 AM
To: Multiple recipients of list = ORACLE-L
Subject: Re:=20 how to reduce SQL*Net more data to client wait = event

Depending on the = application, couldn't=20 these large pauses be performance problems in the client=20 program?  Not a server tuning issue nor a SQL*Net tuning issue = at=20 all?  For example, if the client program was pausing a long = time=20 between FETCH commands, processing previously fetched data?  Or = would=20 that just be accounted for under "SQL*Net message from = client"=20 events?
----- Original Message ----- =
From:=20 Suhen Pather =
Sent: Monday, August 19, = 2002 8:08=20 PM
Subject: how to reduce = SQL*Net more=20 data to client wait event

Hi,

 

I am tuning a system = at a=20 client site and notice lots of waits for SQL*Net=20 more data to client (97%) for a fraction

of the CPU consumed by the=20 system.

 

I know this is not = to be=20 characterized as an idle wait event and can yield better = performance if we=20 increase

the packet=20 size.

The database is = Oracle 7.3.4=20 (SQL Net 2.3).  What effect will increasing TDU and SDU have=20

on this wait to = increase=20 packet size.

 

It seems that if we can reduce this wait = then we=20 can save lots of time (I Think).

 

Will using BEQ protocol help at=20 all.

  

Regards

Suhen  

 

 

------=_NextPart_000_000E_01C24955.F9ADCD00-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Anjo Kolk INET: anjo@oraperf.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@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).