RE: SQL*Net Message to client wait on batch job
- From: "Thomas Biju" <BThomas@xxxxxxxxxx>
- To: "Wolfgang Breitling" <breitliw@xxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 23 Aug 2004 10:40:01 -0500
Thank you Wolfgang for putting me back on track... Yes, I need to investiga=
te this... As I was seeing the "SQL*Net" messages, I thought that
is a problem, especially in a batch job. Did not pay attention to the cr r =
values...
Thanks.
-----Original Message-----
From: Wolfgang Breitling [mailto:breitliw@xxxxxxxxxxxxx]
Sent: Monday, August 23, 2004 10:33 AM
To: oracle-l@xxxxxxxxxxxxx; Thomas Biju
Subject: RE: SQL*Net Message to client wait on batch job
Are you sure that the "sql*net wait to client" are the problem? I mean they=
ARE=20
a problem, but I can't see that they are responsible for the slowdown as th=
ey=20
would have been there in 8i as well, unless sqr and the 8i database were
running on the same host using two_task protocol and the Oracle 9i database=
is=20
now on a different host and you have network latency to deal with.
I noticed that the one select in you trace snipped took 13 seconds elapsed =
and=20
cpu, 177,000 consistent reads and 3 physical reads to fetch 3 rows. If that=
is=20
an isolated sql it won't be a concern (although 177,000 cr to get 3 rows se=
ems=20
a bit excessive) but if the sqr is doing 10s or 100s of them they add up.
Compare the plan for this, and other sql, with the plans in 8i. There were =
lots=20
of changes in the 9i optimizer and some of them may bite you, particularly =
in a=20
Peoplesoft environment.
Quoting Thomas Biju <BThomas@xxxxxxxxxx>:
> Thank you. Unfortunately, this SQR was working good in Oracle8i and not s=
o =3D
> good in Oracle9i. So it is "obviously" a database issue. :-)
--=20
regards
Wolfgang Breitling
Oracle 7,8,8i,9i OCP DBA
Centrex Consulting Corporation
www.centrexcc.com
___________________________________________________________________________=
__________________________________
This electronic transmission and any attached files are intended solely for=
the person or entity to which they are addressed and may contain informati=
on that is privileged, confidential or otherwise protected from disclosure.=
Any review, retransmission, dissemination or other use, including taking a=
ny action concerning this information by anyone other than the named recipi=
ent, is strictly prohibited. If you are not the intended recipient or have =
received this communication in error, please immediately notify the sender =
and destroy this communication.
----------------------------------------------------------------
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:
