Re: MS SQL Server Evaluation

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1079138269.352310_at_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"!

I think that's my point (though it's not my name!). Lots of people believe all this cache fusion baloney, as though Parallel Server was just a bad dream. It's still here, though. New name, same issues (reduced, undoubtedly. But not eliminated).

> An application does not need to be designed for RAC.

Disagree, actually.

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

Whatever. We're not going to agree on this. RAC is nice, but its not a silver bullet, that's all I was trying to say. Yet I see people purchasing it precisely because it *is* being touted as painless scaleability.

But on the business of 'designing to scale'... presumably you use sequences? No problems in a single instance environment, I'm sure. Looking forward to the additional overhead of co-ordinating the sequence number allocations across instances when your 'cached and ordered' sequence gets migrated to a RAC? That which was designed to scale in a single instance environment has a whole new set of problems to cope with in a RAC, and problems which will squash a lot of otherwise fine scaleable applications.

It isn't by accident that Oracle's own RAC course notes have this to say on index leaf node contention (I realise this is just one topic, but perhaps you'll get the idea):

"Restrict changes to a single instance" [let's just pretend we're not running RAC at all, shall we??!]
"Partition tables and underlying index" [let's just shell out some extra money for the partitioning option shall we??] "Use instance-specific sequence generators" [let's pretend we're not running RAC *AND* re-code the application]
"Use a multiplier to create distinct ranges" [Still re-coding I see] "Consider reverse key indexes" [Uh huh. I quite like block splits anyway].

I mean, why just they don't come clean and say "leaf node contention potentially becomes a real bugger of a problem in a RAC in a way you'll never have experienced it before in a single-instance environment and there are no easy fixes for it".

I bet the sales guys don't mention that bit.

Freelist contention likewise. "Oh", Oracle says, "we have a fix for that: ASSM". And it's true. It fixes freelist contention at a stroke... but at what cost in buffer cache usage? They kind of don't mention that bit either. I could go on, but I doubt you'll buy it, because you give the impression of having bought into the RAC hype.

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

Oh Daniel. It isn't difficult to *build*. It's difficult to *tune*. Because there is zilch help from Oracle, and there's a lot of degrees of freedom to eliminate when assessing cause and effect.

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

Maybe you should take *my* class, then. It switches *off* cache fusion, precisely because cache fusion puts a frequently unbearable burden on the node interconnect. In effect, your RAC, for the defined data files, becomes merely Parallel Server, leaving the interconnect free to handle those things which actually need the near-millisecond response times which cache fusion can sort of, more or less, maybe deliver. It's given rather a lot of prominence in the Oracle 9i RAC course notes, which should tell you something.

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

GC_FILES_TO_LOCKS is an extremely important part of any RAC tuning strategy. Just because Oracle provides cache fusion by default doesn't mean its free, painless or right. And that, I suspect, is my point. There are too many people out there thinking that OPS is dead and buried and RAC has descended from Heaven as some form of magic being, never seen before, and with all the answers. It isn't. It's OPS with knobs on... and whilst the knobs are rather nice, the fundamental physics of OPS haven't changed.

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

And that would probably be a mistake. The complexity quotient in their system has just gone up an order of magnitude.

>You keep thinking
> technology drives our industry. Those days are ending. Now it will be
> ROI that drives it more and more.

Try not to tell me what I'm thinking. It's precisely because ROI should be looked at that RAC and grid probably shouldn't be, for most people, most of the time.

> > 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 doubt they would save anything. This crappy idea that RAC is "easy", whereas OPS was "difficult" is really bad consultancy-ing, actually.

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

Again, RAC *costs* money, and I'm not talking about license fees. Application re-design. Performance tuning trouble-shooting. DBA training. Risk and complexity management. You name it.

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

Dreams and reality, Daniel. Dreams and reality. Not the same thing at all.

> Once again ... any sane person ignores the hype.

Well, no actually they don't. At a rather large district health board of my recent acquaintence, they have just purchased RAC. They don't need it. They don't know what to do with it. They don't yet have the skills to manage it. But they've bought it all the same, for reasons which I'm sure they can justify in the long term, to their own satisfaction at least. The true story however appears to be they were offered a deal on an interesting-sounding technology (RAC) by their (Oracle) sales representative, so they took it. A story rather more common, I fear, than you would like to believe. Now I get called in to make the thing work for them. And I don't come cheap.

If only they'd left well alone, because it was all working rather nicely for them up to that point.

And although they have a rather large psych. unit in their near-neighbourhood, not one of them is actually insane.

Regards
HJR Received on Fri Mar 12 2004 - 19:14:36 CST