RE: SQL*Net Message to client wait on batch job

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 23 Aug 2004 10:38:35 -0500

I rescind my "the [only]" comment.

I assumed from the context of the original post that the dominant
contributor to response time was the "SQL*Net..." event pair. I shouldn't
have assumed that.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte, 10/26
Toronto
- SQL Optimization 101: 8/16 Minneapolis, 9/20 Hartford, 10/18 New Orleans
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Cary Millsap
Sent: Monday, August 23, 2004 10:05 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: SQL*Net Message to client wait on batch job

Thomas,

I agree with Stephane; the [only] way to fix this problem is to stop =
your
application from making so many database calls.

A couple of added bits of information:

- The p1=3D1 value for "SQL*Net message to client" events is described =
in
V$EVENT_NAME as "bytes," but it is not a correct byte count. You can =
confirm
this by using truss (strace, etc.).

- The duration of "SQL*Net message to client," as far as my tests have =
been
able to tell me, is /never/ dependent upon network load. The event maps =
to
an OS write(SQLNET_OUT, ...) call. The latency of that write call does =
not
include any time spent on a network.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte, 10/26
Toronto
- SQL Optimization 101: 8/16 Minneapolis, 9/20 Hartford, 10/18 New =
Orleans
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Stephane Faroult
Sent: Monday, August 23, 2004 9:54 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: SQL*Net Message to client wait on batch job

 Thomas,
    Those waits are typical of a 'line-by-line' logic. The remark in =
Kirti's
book applies to (specifically) 'to client' (as opposed to 'from client')
waits. Here you have both, which means that most of the time is spent
blabbing on the network. I am ready to bet your insert is in a loop. If =
you
really love loops, try to call a stored proc instead. But some INSERT =
...
SELECT ... would be far, far better.

HTH,=20

Stephane Faroult=20

On Mon, 23 Aug 2004 09:41 , 'Thomas Biju' <BThomas@xxxxxxxxxx> sent:

Hello gurus,

We upgraded Peoplesoft to Oracle9i over the weekend. So far everything =
work=3D
s great except one batch job. Did an extended trace and the waits
are on SQL*net message event. I got the driver id and bytes (always 1 it =
se=3D
ems!!) from the trace file. But do not know where to go from
here. Kirti's book says "the client process may be too busy to accept =
the d=3D
elivery of message". How do I verify this?=3D20

Here is few lines of the trace output:

PARSING IN CURSOR #25 len=3D3D300 dep=3D3D0 uid=3D3D614 oct=3D3D2 =
lid=3D3D614 tim=3D3D2=3D
08054417239 hv=3D3D33
01285365 ad=3D3D'44820a70'
INSERT INTO PS_BR_PYT_PROJECTS (BUSINESS_UNIT, PROJECT_ID, BR_PAYOUT_ID, =
AC=3D
TIVIT
Y_ID, ACCOUNT, ACCOUNT_TYPE, ACCOUNTING_DT, RESOURCE_ID, JOURNAL_ID, =
JOURNA=3D
L_LIN
E, PRODUCT, CURRENCY_CD, BR_AO_PROP_XREF, ACTIVITY_TYPE, AMOUNT) VALUES =
('B=3D
R', :
1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14)
END OF STMT
EXEC =
#25:c=3D3D0,e=3D3D627,p=3D3D0,cr=3D3D0,cu=3D3D8,mis=3D3D0,r=3D3D1,dep=3D3=
D0,og=3D3D4,tim=3D
=3D3D208054417197
WAIT #25: nam=3D3D'SQL*Net message to client' ela=3D3D 5 =
p1=3D3D1229996800 p2=3D3D1=3D
p3=3D3D0
WAIT #25: nam=3D3D'SQL*Net message from client' ela=3D3D 862 =
p1=3D3D1229996800 p2=3D
=3D3D1 p3=3D3D0


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: