| 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: Re[2]: SPEED-UP OPERATION
This problem is related to one I had to look at before.
I am with Stephane, first a TKProf will show problems in SQL and data structures. If that is ok, then the problem can be attributed to something along the lines of network, server usage, client machine, forms layout of execution and other dependencies, etc.
Akshay Jain
-----Original Message-----
From: Rachel Carmichael [mailto:carmichr_at_hotmail.com]
Sent: Sunday, June 04, 2000 12:14 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Re[2]: SPEED-UP OPERATION
hang on, if the SQL itself runs quickly, but it takes time to switch forms or finish the inserts... has anyone looked at the network???
Kristen has said that the I/O, etc is running fine when run in isolation. So
the problem may be somewhere else
I am presuming that whenyou tested the SQL, you did it on the server.
Do the same test connecting to SQL*Plus from a client... if there are network problems, you should see a slower response.
That;s a start anyway
>From: "Thomas L. Harleman" <tharleman_at_iquest.net>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: RE: Re[2]: SPEED-UP OPERATION
>Date: Sun, 04 Jun 2000 05:56:23 -0800
>
>Some things to think about:
>Has data entry into the database always been slow?
>Were the RDBMS files distributed using Oracles Optimal Flexible
>Architecture
>(OFA)?
>Do you have too many, unnecessary indexes on your tables?
>Have you indexed all foreign keys?
>
>Tom Harleman
>11080 Willowmere Dr.
>Indianapolis, IN 46280
>317-844-2884 Home
>317-843-9122 Home Office
>
>ThinkFast CONSULTING, Inc. (formerly Pinnacle Solutions)
>Technical Consultant
>3500 DePauw Blvd. Suite 2071
>Indianapolis, IN 46268
>tharleman_at_thinkfast.com
>317-334-1317 Office
>317-334-1301 Fax
>
>
>
>-----Original Message-----
>Cameron
>Sent: Friday, June 02, 2000 5:56 PM
>To: Multiple recipients of list ORACLE-L
>
>
>The problem with finding the bottleneck is that the users
>are not using the application because it is so slow. The
>database is a reference library of sorts. Even when in use,
>only three or four users at a time may be adding entries.
>I'm not sure of the number of users querying the database,
>but it would only be a few a day generally.
>
>For the moment, the users are recording the information on
>paper for later entry into the database.
>
>So, how the heck do I figure out what is wrong?
>
>I asked the users to do some work in the application for a few
>hours a couple of weeks ago and found absolutely no problems
>with IO, cpu, or anything else I could think of to check. I used
>bstat/estat and a variety of performance tuning scripts. It can
>take minutes (3 to 10) for an insert or update via the application,
>and even switching between forms takes 30-60 seconds,
>but the SQL involved runs in hundredths of a second when run
>on its own.
>
>Sigh. I think I'm going to have to learn Oracle Forms next so
>that I can figure out what is going on.
>
> >>> stephane_paquette_at_yahoo.com 6/2/2000 >>>
>Have you identified a specific bottleneck ?
>Is it IO or cpu ?
>How do you checked the SQL ? Personnaly I used tkprof.
>
>
>
>
>--- Kristen Cameron <cameronkgd_at_inac.gc.ca> a ecrit :
> > I'm trying to speed up an application built using
> > Forms 4.5. I have extracted
> > all the SQL executed by the application (30+
> > statements) and am checking
> > them, but see no problems thus far. I have already
> > checked the usual suspects
> > (hit ratios, swapping and paging, etc.) and have
> > discovered that the
> > database itself runs beautifully!
> >
> > Is it possible that the coding within the Form
> > itself causes it to run slowly?
> > I don't mean the SQL code, but the code that Forms
> > uses. There are
> > triggers etc. built into the forms that do not
> > access the database.
> >
> > Any comments or suggestions?
> >
>
>
>--
>Author: Kristen Cameron
> INET: cameronkgd_at_inac.gc.ca
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
>
>--
>Author: Thomas L. Harleman
> INET: tharleman_at_iquest.net
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
-- Author: Rachel Carmichael INET: carmichr_at_hotmail.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Mon Jun 05 2000 - 09:37:14 CDT
 |
 |