Re: MS SQL Server Evaluation

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 12 Mar 2004 21:23:58 -0800
Message-ID: <1079155446.258063@yasure>

Howard J. Rogers wrote:

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

So much for going back end editing and not proof reading.

RAC is not OPS. There is not a single line of OPS code in RAC as far as I know. It is a completely different animal built on the fact that everyone agrees that OPS was a good concept and a bad implementation.

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

I never said it was a silver bullet: That is your phrase. If people purchase it for the wrong reason ... and I see that too ... shame on them. I see people purchase Siebel too. Caveat emptor. But back to your point ... if ignorant people buy things for the wrong reason whose fault is that?

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

Why coordinate sequences? Use a single sequence and let your code use a little formula bassed on instance number to make them unique or use SYS_GUID.
> 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??]

If Larry can get them to part with their money that's part of his job. But since we all know that RAC is now included in SE obviously that isn't a requirement.

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

Or alternatively, as we do, just have your code use the instance number and a simple formula.

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

They probably don't understand it either.

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

Everything is a trade-off. You expect something for nothing?

>>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 there are classes. The key to successful backup and recovery is education. The key successful implementation of anything is education. When you buy a car do you expect the dealer to teach you how to drive? When you buy a turkey (if they have turkeys in Oz) do you expect the grocer to teach you how to cook? Why expect Oracle to do anything to teach you how to implement their products.

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

Tells me the course notes are worthless. That's what it tells me.

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

You say it is important. I can point to one of largest , if not the largest RAC implementation and it is ignored with no consequences.

Here's what I find in the Oracle on-line docs:

GC_FILES_TO_LOCKS is an Oracle9i Real Application Clusters parameter that has no effect on an instance running in exclusive mode. It controls the mapping of pre-release 9.0.1 parallel cache management (PCM) locks to datafiles.

I'm serious ... what you consider an issue ... is ignored without consequence.

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

Then please explain why you think the ROI is better on a single 16CPU machine rather than 8 2CPU machines. I have the quotes here from several implementations and I can't fathom how you are coming to your conclusion.

>>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'll grant you the training cost. But unless someone is learning it somewhere I'm not aware of ... it should be minimal. Certainly less than $2000/dba.

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

I could say the same thing for almost everyone that owns Microsoft Office without exaggeration.

> Regards
> HJR
Caveat emptor.

It seems like you criticize the technology as being unnecessary for most organizations. You criticize it because ignorant people purchase it. You criticize it for not being perfect. I'll grant you all of that. Why is that anyone's fault but the customer for not hiring you or me, or someone like us, to advise them? The fact that someone can buy a boat doesn't make them a sailor.

-- 
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 - 23:23:58 CST