Re: Performance problem .... HELP :-(

Hi Ian,
 

take a careful look at fragmentation of their indexes and possible chained rows in the tables. Probably RATE_SCHEDULE_LINK_PK is a good start point
Also the cardinality (estimated numbers of output rows for each step) may confuse you if their statistics is lost or obsolete for some objects
 

Regards,Ed
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

• Original Message ----- <DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: Biddell, Ian To: <A title=ORACLE-L_at_fatcity.com href="mailto:ORACLE-L_at_fatcity.com">Multiple recipients of list ORACLE-L

  Sent: Wednesday, December 19, 2001 1:50   PM
  Subject: Performance problem .... HELP   :-(   

  Hi all, <FONT face=Arial
  color=#0000ff size=2>Hoping someone can shed some light on a problem I have.   We a particular cursor in a
  batch program running in production at a client site which has suddenly   decided to work really badly.
  The program hasn't been changed but I   think the customer has done some sort of reorg on the database.   I traced the program on their
  server and also on a copy of the database on our server (our copy taken before   the reorg) <FONT face=Arial color=#0000ff   size=2>As can be seen from the tkprof output from a trace on the program for   about an hour theirs does a lot of buffer IO for few rows returned compared to   ours.
  The execution path
  in the explain is the same but the row counts down the side are   different.
  Does anyone have any
  idea why this would be happening or what further investigation I can do.    All
  access is via PK so it should be flying like the second example.    Received on Wed Dec 19 2001 - 10:01:28 CST