Re: Performance Issue

From: Mark Malakanov <markmal_at_sprint.ca>
Date: 1999/10/12
Message-ID: <1MyM3.4723$j35.167953_at_newscontent-01.sprint.ca>#1/1


[Quoted] 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 [Quoted] "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 - 00:00:00 CEST

Original text of this message