Re: justification of tuning effort

  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. Received on Thu Jan 13 2000 - 15:44:23 CST