Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: MS SQL Server Evaluation

Re: MS SQL Server Evaluation

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Sat, 13 Mar 2004 19:06:16 +1100
Message-ID: <4052c0ff$0$8360$afc38c87@news.optusnet.com.au>

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

Are you sure your students don't get to post under your name, Daniel? Because only a student with a limited grasp of the facts could make that statement.

The clues are there all over. The Global Enqueue Service is known by the
process abbreviation ...er... LMD. Uh huh. The Global Cache Service is known
by the process abbreviation... er... LMS. Gosh. I wonder why "Global Enqueue
Service" gets abbreviated as LMD. It wouldn't perhaps have anything to do with fact that OPS had a process called Distributed Lock Manager would it?? I could go on, but I won't bore you. RAC is OPS with knobs on.

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

Marketing hype, actually.

>
> > 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.
That's presumably why Oracle expended considerable effort in getting 9i release 2 to coordinate sequences across instances, then, yes?

It is easy to trot out trite answers in this forum. It is rather different in the real world. Business decisions are not always capable of being subject to such simplistic analysis.

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

Bit of a non-sequiteur. I mentioned the partitioning option, which still costs money. Not RAC. Which will still cost you money even if included free.

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

The code that you were not supposed to have to re-write to have it run on a RAC. The "Real" Application isn't sounding quite so real now, is it?

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

Thank you. You've made my point for me yet again. RAC isn't free of trade-offs either. And most people will find the costs outweigh the benefits.

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

Well, I'm afraid it tells me that on this particular topic you don't actually know very much about what you're talking about.

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

Crap. Sorry, but that's all that anecdotal stuff is. You are free to ignore the parameter if your interconnect isn't under strain. For many two-node clusters, it won't be. But as the number of nodes goes up, the amount of inter-node messaging goes up, exponentially. Assuming we are taking Cache Fusion at face value that is, and we haven't sneaklily partitioned our application to prevent cross-node transfer. When the interconnect is under strain, it pays to know how to alleviate the burden. GC_FILES_TO_LOCKS is still there for a reason.

> 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 don't care what you find in the online docs, because it is painfully apparent you've never actually met this parameter in real life before. It's also painfully apparent that the online doco. is a trifle thin on the subject.

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

Because I have some understanding of the complexity that multiple instances will bring to the environment, and take those extra hassles into account.

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

Yes, and shortly you'll be able to get an OCP in a week. Do you think that impresses me? Would it impress you? You don't learn RAC in a threep-day course.

> It seems like you criticize the technology as being unnecessary for
> most organizations.

I don't criticise the technology at all. It is a fine technology, as I've said repeatedly. But it is overkill for most people.

>You criticize it because ignorant people purchase
> it.

No, I criticise Oracle Marketing for suggesting that RAC is suitable for everybody, can help everybody, and is of immediate benefit to everybody.

>You criticize it for not being perfect.

I don't criticise it. Read my lips: it's a fine product. But physics are physics, and marketing hype that ignores that is to be criticised.

>I'll grant you all of that.

Gracious of you, I'm sure. But I never actually said any of it.

See if I can make it any clearer (for the last time) this way.

I have a barrister friend who has a rather ancient (3 years+) computer in his chambers. Every time I visit him, he badgers me to upgrade him to Windows XP, and when I explain his old CPU won't be up to the job, he badgers me to buy him a newer computer. He's heard something about hyperthreading and thinks he ought to have that.

I ask him what he actually does with his computer. He types perhaps 4 letters a day. In wordpad. He receives email, via dialup. He browses a few websites. And that's it.

He doesn't need a hyperthreading CPU to do any of that, I gently explain. And we go to lunch without him shelling out a couple of grand for something he doesn't need. I once relented and helped him purchase an LCD monitor, because it meant he re-acquired a square foot of desktop space he could clutter up with something other than his CRT monitor.

As my part-time client, he calls the tune and foots the bill. But I won't recommend he upgrades when he actually doesn't need it.

That's all.
HJR Received on Sat Mar 13 2004 - 02:06:16 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US