Re: Performance Issue

Thanks for asking Mark. The problem is that whenever that functionality is evoked nothing else can occur on that box. As soon as the job is over (which is every hour on the hour) the system goes back to normal. The happenings at that particular time are updates, deletes etc to the table in question and the replication job that pushes the changes from one machine to the other. Let me know if you can help.

                                                        Tapan

Mark Malakanov wrote:
>
> Don warry about chained rows. You have only 0.003% chained rows.
>
> What is "a performance problem associated with a particular functionality"?
> Access time? Long selects? Long changies? Locks? Space shortage? Errors like
> "Unable to create (sort/rollback) extent"?....
>
> Mark Malakanov,
> OraDBA,
> Sapience, Toronto
>
> Tapan Trivedi <tapan.trivedi_at_abbnm.com> wrote in message
> news:3801F953.C8CD2010_at_abbnm.com...
> > Hi Guys,
> > I have a client who is screaming of a performance problem associated
> > with a particular functionality. All the tables for that functionality
> > are in a single tablespace. All the indexes in a different tablespace.
> > All the tables for that functionality look ok except for one ESDATA.
> > This is the main table which is the most used which has a next extent of
> > close to 50m. The average next extent for all the objects is around 2m.
> > Is there something I can do towards this. The table has around 5.7
> > million rows and about 19000 chained rows. What can I do about the same
> > ? I am concerned as this is a replicated environment and anything that I
> > do has to go over to the next side. Any suggestions,comments,experiences
> > are welcome.
> >
> > Thank you.
> > Tapan H Trivedi
> >
> > SQL> select
> > SEGMENT_NAME,BYTES,EXTENTS,INITIAL_EXTENT,NEXT_EXTENT,MIN_EXTENTS
> > 2 from dba_segments where extents > 20;
> >
> > SEGMENT_NAME BYTES EXTENTS INITIAL_EXTENT NEXT_EXTENT
> > MIN_EXTENTS
> > -------------------- ---------- ---------- -------------- -----------
> > -----------
> > EVTAUG 75581440 37 10240
> > 2097152 1
> > ESDATA 195174400 69 2097152
> > 52428800 1
> > EVTMSG 100771840 49 10240
> > 2099200 1

Received on Tue Oct 12 1999 - 09:07:33 CDT