| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: justification of tuning effort
buckeye714_at_my-deja.com wrote:
>
> You said it yourself. The biggest justification for tuning is to
> improve response time for the user. I have talked to several other
> DBA's and it seems to be a common idea that tuning for tuning's sake is
> not a good use of time.
> I just started working here a couple of months ago. Recently I found
> out that the tablespaces for one of our big apps had never been
> reorg'ed. So, I found out what report ran the longest, which
> tablespaces the biggest tables the report used were in and reorg'ed that
> tablespace over the weekend. On Thursday, the report ran for over 14
> hours. After the reorg, it ran in just over two hours. Now, the
> users are coming to me with ideas on the next tablespaces to reorg,
> and just last week they didn't care on way or the other. This is an
> extreme case, but it justifies the work.
> So, I guess the point of my rambling is, tune only if the users will
> see an increase in performance.
> In article <85ldc2$hi3$1_at_nnrp1.deja.com>,
> michael_bialik_at_my-deja.com wrote:
> > Hi.
> >
> > I usually do it other way:
> > I start with tuning resource hungry sql statements first.
> > In that case I'm able to show the client immediate improvements (
> > That screen/report took n minutes/seconds - now it takes a small
> part
> > of it ).
> > It even may improve hit ratios without playing with init.ora ( less
> > FULL scans etc. ).
> >
> > HTH. Michael.
> >
> > In article <85kvaq$5vm$1_at_nnrp1.deja.com>,
> > Ed Stevens <Ed.Stevens_at_nmm.nissan-usa.com> wrote:
> > > Ok, I just returned from the Oracle Performance Tuning Workshop.
> Now
> > > I’m getting into setting up some monitoring with UTLBSTAT/UTLESTAT,
> > and
> > > playing around with Oracle Expert and some other OEM tools. Once
> I’ve
> > > got some regular monitoring going on (I’m running BSTAT/ESTAT
> against
> > > every database once per week) I’ll be ready to attack.
> > >
> > > However, in the end I’ve got to be able to show my boss (and myself,
> > > and the end user) some meaningful results. Improving hit ratios and
> > > physical I/O and all the rest is well and good, but at the end of
> the
> > > day the only thing that really counts is reducing response time for
> > the
> > > user. I’ve been poring over the REPORT.TXT out of UTLESTAT, looking
> > > for some stats that will be meaningful in this “final analysis.”
> This
> > > is not to be confused with the wealth of stats that help explain WHY
> > > the end user is experiencing a certain level of performance. I’m
> > > looking for the number (or small group of numbers) that can show
> > > managers and end users that “I made such-and-such change, and here’s
> > > where it improved your performance.”
> > >
> > > I know that as we get into the thick of tuning and administering a
> > > database, this can seem overly simplistic, but then I’m trying to
> show
> > > results to overly simplistic management/users. The guy who pays the
> > > bills really doesn’t care about “sql area get hit ratios” or “DBWR
> > > checkpoints” or any of that stuff. All he cares about is how fast
> he
> > > gets his results, and why he’s running out of disk space. And if
> they
> > > feel that current performance levels (whatever they are) are
> > > acceptable, there is a very good chance that they won’t perceive any
> > > performance improvement as a result of any tuning efforts, leaving
> me
> > > wondering how to justify the effort.
> > >
> > > --
> > > Ed Stevens
> > > (Opinions are not necessarily those of my employer)
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> > >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Valid points - but also, with statistics such as growth of objects over time, combined with the number of queries that perform full scans, you can start to make predictions about when response times WILL become a problem even if they aren't now...
This helps identify potential problems as well as current ones...
Cheers
--
"Some days you're the pigeon, and some days you're the statue." Received on Sun Jan 16 2000 - 05:50:36 CST
 |
 |