Re: MS SQL Server Evaluation

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1079132044.292409_at_yasure...
> Comments in-line.
>
> Howard J. Rogers wrote:
>
> > "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
> > news:1079112892.570278_at_yasure...
> >
> >>Howard J. Rogers wrote:
> >>
> >>I think you are wrong on several counts.
> >
> >
> > That of course is everyone's privilege!!
> >
> >>The main reason I see for
> >>RAC is build-out rather than build-up. It can save a boatload of
> >>money building a 16CPU machine with 8 x 2CPU Intel machines rather
> >>than talking to HP, Sun, or IBM about a 16CPU box. And with that
> >>boatload of money both Larry and his customers can buy their boats.
> >
> >
> > That of course rather presupposes that the 8x2 solution works as well as
the
> > 16 cpu solution. I'll lay odds up front that it wouldn't. Cache Fusion
> > sounds great in the marketing material but it's just a lot of old
> > inter-process messaging under the hood, all of which takes time and
effort
> > on the part of Oracle. You've still got the issue of forced disk writes.
And
> > the interconnect had better be up to the job.
>
> Unless you got a very poorly written application ... the number of
> blocks that need to move between nodes should be minimal.

Eh? Then you would be using an old Parallel Server application which had application partitioning issues dealt with as part of its design. If, on the other hand, you take Oracle at its literal word ("Real" applications, not specifically designed for a clustered environment, are supposed to take to RAC like a duck to water), then you can expect to see buffers fly across the interconnect at a rate of knots. That, after all, is the entire point of "Cache Fusion". And "Load Balancing".

>But from my
> experience benchmarking RAC ... you get about 88% of the performance
> for 25-40% of the cost. And that's after paying Larry his due.

Well, I'd dispute those figures, because I'm convinced they don't take into account the DBA time spent managing what is now a very complex beast indeed.

> > And by the time you've paid the consultant to set GC_FILES_TO_LOCKS
> > properly, you could probably have purchased the 16 cpu box twice over
with
> > enough left over for a small yacht.
>
> Or for very few dollars you could take a class and learn to do it
> yourself. There is absolutely no need to pay the consultant unless
> you have more cash than incentive.

You miss my point. *No-one* knows how to set GC_FILES_TO_LOCKS properly (possibly Steve and Jonathan aside). How many multi-block locks do you set for a file? To what degree do you group them? What statistics do you turn to to tell you you got it right or wrong, or what advisories does Oracle provide to allow you to predict what ought to be reasonable settings? The advice is poor, and there are few good indicators. There is no Oracle class that I know of that teaches you these things. I would hazard a guess that I know rather more about RAC than most people and *I* can't set GC_FILES_TO_LOCKS with any huge degree of confidence that I've got it right beforehand.

>
> >>Failover will become a larger part of the equation when Oracle makes
> >>good its promise in a later release of 10g to make Oracle Forms, etc.
> >>failover which means we will finally be able to have failover with
> >>Oracle's own apps.
> >
> > You believe these promises!?
>
> I have reasons to. And I'll leave it at that.

I remember them promising it two years ago. I'll leave it at that, too.

> >>And grid? If you have 10g what is the extra cost for grid?
> >
> > Performance and productivity, which will go down the tubes the minute
the
> > DBA starts experimenting with it in those environments that have no use
for
> > it.
>
> When you have actual benchmarks that back this up let me know. That
> is not my experience and I have it installed.

I don't need to quote benchmarks for this Daniel. It's a qualitative thing, not a quantitative one. My point is that most people don't need grid, and won't need it. But the minute you start introducing that level of complexity, you are going to compromise what was an efficient grid-less working environment.

> > But as I think Niall put it in another thread: there was a time when 8.0
did
> > all that we could ask of it, and we were happy. There will always be
some
> > that need the new features, but I don't believe business needs have
changed
> > *so* much since 8.0 that there will be a sudden rush for grid technology
now
> > that it's available from SME's.
> >
> > Regards
> > HJR
>
> Business needs have changed dramatically. You'd never run Amazon.com on
> 8.0.

Thank you. You've just made my point for me. Of course there are Amazons and NASAs out there. But their experience is a-typical, and whereas they are prime candidates for using these new technologies, I'd guess 80% of all the Oracle databases on the planet have no need for them. That's all. I'm not saying the new technologies are evil, bad, don't work or are a terrible travesty of pure intellectual thought. They are *good* technologies. And if you have a need for them, then they should be employed. But most people don't.

>Nor build some of the apps I've worked on for telecoms. Lets be
> honest here Howard ... anything can be built in assembly language. It
> just takes more time and costs more money. Therefore we use C and C++.
> Just about anything can be built in C or C++ but it takes more time and
> costs more money therefore we buy database software from vendors like
> Oracle. Just about anything could be done with Oracle version 6 but it
> takes more time and costs more money therefore we use the latest tools.
>
> And unless we don't know how to use them effectively they save time and
> money. The problem is the "unless" and I think you just like bashing
> Oracle for the pure sake of bashing Oracle.

I've not "bashed" Oracle at all. I've said merely that the sexy stuff sells, but most people don't and won't need it. Further, that most people have been beguiled by the sexy stuff into making purchases that a serious, objective assessment of their business needs would have advised them against making.

I think Oracle is an extremely fine product. I wouldn't have invested the last several years of my life in researching the thing if I didn't. If you have a use for these features, fine. I'm not going to stop you using them, and in the right circumstances, I would advise that you *did* use them. But those are the magic words: "right circumstances". Instead of stampeding for the marketing hype, businesses actually should take the time to assess their circumstances and needs. RAC drops out of the equation for many when that is done properly. And grid won't even be a twinkling on the radar screen for many for the same sort of reasons.

>If you compare them against
> some standard of perfection they should burn the place to the ground and
> go home. But if you compare them against IBM, Sybase, and Microsoft I'd
> think you'd be pretty happy with the company Larry's built.

This isn't about "being happy". It's about making wise business choices, as opposed to fashion-driven or hype-driven ones.

Regards
HJR Received on Fri Mar 12 2004 - 17:33:01 CST