Re: MS SQL Server Evaluation

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 12 Mar 2004 16:37:44 -0800
Message-ID: <1079138269.352310@yasure>

Howard J. Rogers wrote:

>>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".

Roger Roger Roger. Are you still believing the puffery put out by marketing departments? Get "Real"!

An application does not need to be designed for RAC. But it does need to be designed to scale. They are not different things. To expect a poorly designed piece of v7 PL/SQL to run efficiently on RAC is no different from expecting to run efficiently anywhere else: Garbage is garbage. RAC just has a way of shining a bright light on it.

>>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.

Take my RAC class. ;-)

If DBAs are spending a lot of time managing RAC ... it is likely that they haven't a really good idea what they are doing. Tomorrow and Sunday we teach two more one day RAC workshops. We start at 9:00am and by 5:00pm we are running fail-over tests. And this is with students not experienced DBAs. So if I can build out a complete four node RAC cluster in two hours, from scratch, exactly how much work can it really be?

>>>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.

And exactly what does GC_FILES_TO_LOCKS have to do with RAC?

Don't tell me you've still got some part of your psyche rooted in OPS and are suffering from RAC_NODE_phobia.

>>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.

I would disagree about whether they need it. If a business has a choice between buying a new expensive piece of hardware or using what they already have with grid ... they will go with grid. You keep thinking technology drives our industry. Those days are ending. Now it will be ROI that drives it more and more.

> 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.

This may be the Australian perspective speaking to the US perspective. I think of Boeing, telecoms, hospitals and major medical centers, credit card companies, dot nets, lumber companies, insurance companies, stock brokerages, etc. all of them big enough to be running major operations.

Just to give you an idea ... AEI Music, a little company here in Seattle that distrbutes elevator music ... has a server room with more than 20 individual servers. They could save a bundle with RAC. And don't think their CFO won't figure that out soon enough.

> 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.

Need as in I need air to breathe and water to drink no? Need as in if properly implemented it makes the organization more profitable? There I would disagree. This is about money Howard: Not technology.

> 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.

I'm not suggesting anyone stampede to grid for flashy technology. I am suggesting they can save money. And while that mey not be your dream it is the fantasy of most top management types.

> This isn't about "being happy". It's about making wise business choices, as
> opposed to fashion-driven or hype-driven ones.
>
> Regards
> HJR
Once again ... any sane person ignores the hype. But then again any sane person sees if they can leverage the underlying technology to their benefit too.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Fri Mar 12 2004 - 18:37:44 CST