Re: DB Buffer Cache Size

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:412a8c87$0$8833$afc38c87_at_news.optusnet.com.au...
> Joel Garry wrote:
>
> > "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> > news:<4128f1c0$0$3928$afc38c87_at_news.optusnet.com.au>...
> >>
> >> It's funny: the Oracle Performance Tuning course has for years been
> >> drumming into people (correctly, IMO) the order of events: Design,
> >> Application, Memory, I/O, Contention, Operating System. Any other order
> >> of events is likely to result in 'loop tuning', where you fix problem
A,
> >> move onto problem B, and find that fixing problem B has re-blown
problem
> >> A.
> >>
> >> No doubt it's lucrative for the consultant. But it's not efficient.
> >
> > It's not efficient if you are looking at the whole life-cycle from the
> > beginning, but that is not the problem being solved when you go in to
> > fix a messed-up system, is it?
>
> See my reply to Niall. It makes no difference. Even a system that's
already
> messed up needs fixing in a *methodical* manner... not just dive in all
> over the place, correcting anything that happens to come to mind in the
> order they happen to come to mind. There has to be a sensible starting
> point, and that's got to be the application design every time.

Well I hope you noticed I didn't advocate random parameter tuning :). My problem from experience is that it generally takes me (and i'm a relatively quick study) about 6 months to work out why apps do what they do. Of course some apps get upgraded on roughly a 6-12 month cycle :). I'm not going to get the design rationale out of the vendor - still less an actual spec. (Hmmm I wonder what the design of Oracle Apps is - perhaps there is a public whitepaper on it).

> > The efficiency must be measured from
> > the correct starting point, and Design is not the starting point in a
> > running system.
>
> Again, see my reply to Niall. Yes, the design IS the correct starting
point,
> even in a shrink-wrapped application, because one needs to know the
> efficiency of the design you're working with before starting to come to
> meaningful conclusions. Is the problem bad SQL? Is it lack of indexes?

Actually i'm going to go with Cary here, and not the Oracle Perf tuning mantra, The starting point, for a production dba, is "what are the processes that are costing my business cash". WTF do we do about them.

> "Design" in that post of mine, in short, doesn't mean "How would I design
> this application if I were writing it from scratch". It means: consider
the
> efficiency of the design you're stuck with. Knowing where even a
> set-in-concrete design is INefficient has got to be your first port of
> call.

maybe we don't differ so much.

> > If your tire goes flat in the middle of Wisconsin do
> > you ship the Nissan back to Japan? How efficient is that? (Some
> > Nissan sports cars have an apparent design defect that causes
> > premature wear on tires).
>
> The art of using analogy is to pick an appropriate one!
>
> If your tyre is flat, it helps to know it's the tyre that's the problem
and
> not your cylinder head or distributor cap. Not much point me getting the
> grommet-levers and flupblingers out when actually all I needed was a car
> jack.

ah yes we seem to be saying much the same - fix the problem having diagnosed it correctly.

> > Speaking as someone who deals more with the low end, I have to agree
> > with Don, when costs are evaluated, quick-and-cheapness wins. I agree
> > with you, the view should be long term, cheapness has its own costs,
> > but the US reality is quarterly accounting. Efficiency for its own
> > sake is not necessarily an ideal solution.
>
> The term "efficient" was shorthand for something which actually addresses
> the issues appropriately and provides a fix which is reasonable, durable
> and affordable.
>
> Buying new hardware when it is not actually required strikes me as an
> unreasonable (as in, irrational) thing to do. It may not fix the problem
up
> in the long-term, and is therefore not actually truly affordable.
>
> Even the lowest end of town must known that 10K today, plus 10K next year,
> plus 10K the year after is not a 'quick-and-cheap' alternative to paying
> 15K-right-now-and-that's-all.

hmmm systems that stay stable for 3 years. I'm sure they exist....

I just don't buy that Oracle corp ever considered folk that buy, as opposed to write systems, when they came up with the perf tuning course. I may have entirely misread it, but "design" in the docs has always to me seemed to imply logical and physical design - this is (with the rather important caveat that generally you can add objects to a physical design - indexes, partitions, mviews etc) generally beyond folk who bought the product once, pay less than 10% of the suppliers yearly revenue in support costs, and have a cross platform supplier to deal with. The material assumes it is your app, with your well defined business goals, that you are designing. I don't live in that world. I live in the 'we bought this - but producing this report that we never tested is slower than a snail on dope' world.

-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com