| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: shot in the dark applications performance problem....
Chris,
This sounds *very* much like a locking (enqueue) issue. Was the application changed in any way (trigger, packaged code, etc.) to use a table row for generating sequence numbers? I have also seen such problems when the key_value is generated as a select max(key_value) from table and everything queues up behind this....
Look at the output of the following query:
Select event, count(*) from v$session_wait Group by event
If you see 'enqueue' in this output with a count of 1 (or more), then this theory is correct. You can then look at V$LOCK, V$SESSION, V$SQL and DBA_OBJECTS to find out further information.... (and the list can help you here with this script).
Hth,
John Kanagaraj <><
DB Soft Inc
Phone: 408-970-7002 (W)
Listen to great, commercial-free christian music 24x7x365 at http://www.klove.com
>-----Original Message-----
>From: oracle-l-bounce_at_freelists.org
>[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Chris Stephens
>Sent: Friday, February 13, 2004 7:34 AM
>To: oracle-l_at_freelists.org
>Subject: shot in the dark applications performance problem....
>
>
>Let me preface all of this by stating that I realize there is
>very little
>chance of a resolution to this from the explanation I'm about
>to give...but
>it thought I'd try and describe the problem here and see if it
>sparks any
>suggestions....
>
>
>The company I work for has outsourced an applications implementation.
>Everything has been running fine. Currently we run 2 call
>center apps out
>of the thing. This past weekend the company changed our
>architecture from a
>1-tier system to a 2-tier system. (not sure if that's standard apps
>architectures or not) When the reps began taking calls after
>that change,
>performance slowed to a halt. They have now been taking phone calls on
>paper for 5 days now. The company has reverted back to the 1-tier
>architecture but the performance problem still exists. The
>people testing
>the system describe the problem as follows:
>
>==
>
>...one person running the call flows=>performance is fine.
>
>
>
>...several persons running the call flows=>EXACTLY 1 minute
>delays between
>screens.
>
>
>
>...several more persons running the call flows=>EXACTLY 2 minute delays
>between screens.
>
>
>
>...several more persons running the call flows=>EXACTLY 3 minute delays
>between screens. (weird)
>
>
>
>==
>
>apparently there is a script that can be run that just goes through the
>screens without running ANY of the database code and the wait
>behavior is
>the same. ????
>
>
>
>I checked the machines involved from top and they are barely
>being worked.
>
>
>
>I checked the waits in the database and the largest event time is from
>'sqlnet message from client'.
>
>
>
>The company restored the system to a previous incarnation and
>it worked just
>fine.
>
>
>
>Something is very very wrong.
>
>
>
>....and thoughts would be greatly appreciated.
>
>
>
>Sorry for the vagueness.
>
>
>
>...questions welcomed.
>
>
>
>Thanks for any info!!!!
>
>
>
>chris
>
>
>
>
>
>
>
>
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request_at_freelists.org
>put 'unsubscribe' in the subject line.
>--
>Archives are at http://www.freelists.org/archives/oracle-l/
>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Fri Feb 13 2004 - 10:10:39 CST
 |
 |