Re: Performance Issue

From: <michael_bialik_at_my-deja.com>
Date: Tue, 12 Oct 1999 20:18:09 GMT
Message-ID: <7u051e$b6q$1@nnrp1.deja.com>

Hi.

 Run :
 SELECT * FROM V$SYSTEM_EVENT ORDER BY 4 DESC;  Before and AFTER execution of your function.  Post the results.
 At least you will be able to see where you are spending  application time.

 HTH. Michael.

In article <380340A5.1A302F6C_at_abbnm.com>,   Tapan Trivedi <tapan.trivedi_at_abbnm.com> wrote:
> This is a multi-part message in MIME format.
> --------------0A2FA80DED9E234BE73B6250
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> 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
> --------------0A2FA80DED9E234BE73B6250
> Content-Type: text/x-vcard; charset=us-ascii;
> name="tapan.trivedi.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Tapan Trivedi
> Content-Disposition: attachment;
> filename="tapan.trivedi.vcf"
>
> begin:vcard
> n:Trivedi;Tapan
> tel;pager:281 262 5866
> tel;home:713 218 8133
> tel;work:281 274 5193
> x-mozilla-html:FALSE
> adr:;;;;;;
> version:2.1
> email;internet:tapan.trivedi_at_abbnm.com
> fn:Tapan Trivedi
> end:vcard
>
> --------------0A2FA80DED9E234BE73B6250--
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Tue Oct 12 1999 - 15:18:09 CDT