Re: New challenge - clustering - do I understand this correctly?

"quarkman" <quarkman_at_myrealbox.com> wrote in message news:oprtsadvbhzkogxn_at_haydn...

>
> Well, I would argue that tuning is very much an on-going process. But your
> mileage might differ, and that's fair enough.
>

Sure. There are always special cases. However, I'd argue that unless the application/site is very atypical, a desirable outcome is to arrive at a balanced performance situation, lock it in and be done with it.

Plan for regular reviews and that's it. Anything more and we're into diminishing returns territory, TCO, etcetc.

> It would be nice if you could just drop two boxes into a production
> environment, set them up once, and then forget about them. But I'd be
> surprised if that's what actually happens to most people.

Well, it is the modern aim of IT. Minimize running costs. Like it or not, tuners are expensive. I don't believe for a second that db software will become so smart it can adapt (and correct) infinitely to bad design/code. It never did, it never will. Not even in semi-autonomous systems like the ones used in long-range space probes. We have some recent well-publicized failures in that area.

What we need is a mechanism that will allow a tuner to examine a running system, find a balanced setup that can provide acceptable (although non-optimal) performance say 80% of the time and lock it in so we don't get sudden blow-outs. If you look at the evolution of access plans, plan stability, hints and stats and all that jazz, it all points in this direction as the future.

There is nothing in RAC/OPS that makes it any different in this regard. It was exactly the same with OPS. Note: I'm not saying we don't need someone knowledgeable to install/setup the whole lot (or even to make sure it is the appropriate solution).

> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

happy with it?

--
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam