the sqlnet is a network issue. talk to your SAs. is the other database on a different
server? work from there.
your big one is your read. could mean your SGA is too small. is anything else running
at this time?
are you sure there is an equivalent amount of work to do? are you sure there isnt
Venu,
Trying to solve the performance issue with a *single* job with Statspack is
like searching for a needle in a haystack, especially in an Oracle Apps
environment. You will need to trace the program *as it runs*, and if you
cannot do that right now, see if you can clone the database to a test
The other database in on a different server.
I looked at the statspack report for the other database, for the time period in
question.
Top 5 Timed Events
~~ % Total
Event Waits
John,
I can run this in our development environment and trace the job. But, the data is
quite a bit larger in production. I can't really take on a refresh/clone now and the
prodcution database is over 600GB
in size. We do have trace for the job which was available because the program
: RE: A performance problem
The other database in on a different server.
I looked at the statspack report for the other database, for the time period in
question.
Top 5 Timed Events
~~% Total
Event
recipients of list ORACLE-L
Subject: RE: A performance problem
John,
I can run this in our development environment and trace the
job. But, the data is quite a bit larger in production. I
can't really take on a refresh/clone now and the prodcution
database is over 600GB
in size. We do have trace
I'm not an Apps expert; but purely from the database perspective, you can
enable 10046 events using dbms_support.start_sql_trace_in_Session( sid,
serial#, TRUE, TRUE). Hope that answers your question.
Arup
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Over what time frame was the statspack report taken. The 5,809,277 cs of db
file sequential read equates to 16+ hours and the 1,960,168 cs of SQL*Net
message from dblink for 5+ hours. Of course, some of these waits could be
concurrent rather than sequential.
But, as John already pointed out,
Venu
You are getting some good advice, but here is a different idea for you
that nobody has mentioned. You say that the job formerly took 1 hour and now
takes 20 hours. You also mention that you have a development environment. If
you can locate the main SQL statement(s), you could run an
) [EMAIL PROTECTED]
Date: 2003/12/29 Mon PM 01:14:34 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: A performance problem
John,
I can run this in our development environment and trace the job. But, the data is
quite a bit larger in production. I can't really take
You are all correct. I am not really trying to figure out why this feed ran 20 hours
from the statspack report. I am trying to find out what if anything happened in the
database that might have
contributed to this job running this long. We do analyze objects in some schemas via a
Concurrent job
Dennis,
Good advice. I will compare the explain plans. I was only half kidding about my head.
As you may know some developers would blame the DBAs for anything they can think of
such as snow, rain, poorly
performing sql they wrote, etc
Thanks,
Venu
-Original Message-
DENNIS
? Dunno,
have not looked.
Thanks,
Jared
John Kanagaraj [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
01/08/2003 01:55 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L
[EMAIL PROTECTED] cc:
Subject:RE: Statspack performance
of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Statspack performance problem
Jared,
Did you snap with the default value of 5? If so, then the SNAP proceduer
will have to scan / sort V$SQLAREA and that can be very time-consuming. If
you are CPU starved or have very high
Title: RE: Statspack performance problem
Jared,
Obvious question, but have to tried to trace it to see which statement it is hanging??
Raj
__
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed
Jared - I am on 8.1.6, but on Unix. How heavily loaded is your system when
you take the snapshot? If it is just normal load, this sounds high. When
I've had a hanging system, several minutes for a snapshot wouldn't be
unusual.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
[EMAIL PROTECTED]
]
01/08/2003 11:21 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Statspack performance problem
Jared,
Obvious question, but have to tried to trace it to see which statement it
is hanging??
Raj
Jared,
Did you snap with the default value of 5? If so, then the SNAP proceduer
will have to scan / sort V$SQLAREA and that can be very time-consuming. If
you are CPU starved or have very high shared_pool access or issues in that
area, then this could explain it Try this with a snap level of
by: [EMAIL PROTECTED]
01/08/2003 01:55 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Statspack performance problem
Jared,
Did you snap with the default value of 5? If so, then the SNAP proceduer
I have seen something like this in the past and it was because there were
two tables - named the same in two different schemas (public synonym,
private synonym and all that mess)..
Do you know whether this could be the same case as yours?
Also check to see if the explain plan differs when u run
I have seen something like this in the past and it was because there were
two tables - named the same in two different schemas (public synonym,
private synonym and all that mess)..
Do you know whether this could be the same case as yours?
Also check to see if the explain plan differs when u run
I have seen something like this in the past and it was because there were
two tables - named the same in two different schemas (public synonym,
private synonym and all that mess)..
Do you know whether this could be the same case as yours?
Also check to see if the explain plan differs when u run
!! Please do not post Off Topic to this List !!
Did you check to see if there is anything else running on the server that might take
resource away from Oracle? It has happened to me once that the SA was
running something that he shouldn't and it's using a lot of system resources.
HTH
[EMAIL
!! Please do not post Off Topic to this List !!
It should be an exact copy as of Aug. 16th. I ran the query on the copy
and on the current production database and the resulting explain plans
were identical except for the number of rows returned. Total execution
time and cpu times were
:
ail.com Subject: Re: Strange performance problem
Sent by:
[EMAIL PROTECTED
25 matches
Mail list logo
