Re: Feedback on please

It's accurate in parts, but misses the point almost entirely.

First off, don't believe all that TPC stuff: benchmarks don't replicate real-world experience, and I'd rather a cache fusion reponse to a query made of a RAC than a union all, which is what you get in SQL Server's federated database.

However, they are correct in many respects: you'd be daft to think you could practically get away with a RAC where one node was powerful and up to the job and the other wasn't. When failover comes, the weaker box likely *wouldn't* be able to cope with the extra load. So that's true: you expect with RACin a co-equal node configuration (which is not a requirement, by the way) to have two identically specc'd machines. Where MS misses the point is that it doesn't have to be a co-equal configuration (you can do primary-secondary, for example), and slow performance on the surviving node may well be better than no performance at all. Or, worse, wrong results from queries... what happens in the Federated model when one of the nodes is unavailable? Do we just miss those rows out of the query results, or what??

They are misleading in their comments on scalability. They themselves admit at one point that adding an extra node increases throughput by 85%. That's a darned sight more than you'll ever see by adding an extra Federation member a la SQL Server.

Costs? Oracle is expensive, no doubt about it. Is that justification for trashing RAC? I don't think so: it's streets ahead of the SQL Server model in terms of high availability and scalability (their own paper admits to the latter).

They miss the point on the interconnect. Oracle didn't just transfer the bottleneck from disk to the interconnect. The interconnect is, of course, a potential bottleneck, but the elimination of the forced disk I/O that you had in OPS is a *huge* improvement, not the minor bit of deckchair shifting that paper implies. The interconnect is always going to be a point of possible contention whatever clustering model you adopt. It is, after all, the thing that makes a cluster a cluster. So what may or may not be true for Oracle's RAC is likewise going to be the case for SQL Server's federations. The real point is, the ceiling is *vastly* higher with the interconnect as a potential bottleneck than it would be with the disk I/O as one. So vastly higher that you'd have to have a maniacally busy OLTP database to even consider it a real problem.

They also stuffed up in their description of the interconnect as "[using] standard Network Interface Cards on each node connected via a hub or switch". At its simplest, yes... RAC can make use of good old 10/100 Ethernet cards, with nothing more than a crossover cable between them. Would I want to go to production with such an interconnect? Hardly. Not a mention of VIA, I notice. Or Gigabit Ethernet. If you describe the interconnect as a naff old bit of crap Ethernet, then yes.. it sounds pretty likely it will become a source of contention. But no-one in their right minds would implement a RAC that way. *Knowing* that the interconnect and its capacity/bandwidth/latency is the key to performance in a RAC, you'd design one from the outset that could cope. If you walk into RAC with your eyes open, the interconnect isn't going to be an issue... at least, not for a long, long time.

Their comments about high availability also miss the point. Yup, it's true that your app. needs to be written to make use of the OCI calls if true *transparent* failover is required (and many are). But RAC provides a highly available environment for any environment, whether OCI-enabled or not -including Excel spreadsheets linked to an Oracle database via ODBC. You can re-connect such a spreadhseet in under 30 seconds. It might not be transparent, but it's certainly highly available. Besides which, what's the alternative? In a federated model, where department 10's records are on database A, department 20's on B, and department 30's on C, then the failure of node B means everything remains entirely available, 100%... provided you don't want to work with any of department 20's data.... at which point, it's not a very highly available model at all.

The only other thing I'd say about the paper is that it is clearly written for Windows users. It says itself that cost savings may well accrue to Unix users. It trashes the idea of costs savings for Intel/Windows Users because, horror of horrors, these people might actually have to invest in some decent kit -such as two decent servers instead of one. I rather thought that was the whole point of co-equal RACs.... you *knew* before you went into it that you had to duplicate your hardware, because the one was backing up the other. Their paper will appeal to anyone who thought they could RAC their quad-processor 16GB RAM box with the Celeron 333 they had lying around in a cupboard somewhere. Which no-one going into RAC with any degree of understanding of it would ever consider doing anyway.

I like SQL Server, I really do. It's dead easy to set up, has an intuitive Windows interface, is cheap and effective for many (but not all) applications. But its clustering technology is piss-weak, and doesn't hold a candle to RAC's. On the other hand, Oracle's capabilities might be overkill for what you need.

Short answer: it's costly, but it *is* far more scalable than SQL Server's clustering offering will ever be. It's high availability is second to none. And benchmarks are meaningless.

Put it this way: I wouldn't be tossing out my plans for 2003 just on the basis of that paper or any other paper like it. The real issues are: what capabilities do you really need, can you afford them, and which product offers them most effectively? Is RAC overkill for your needs? You'd be buying a decent interconnect whichever way you went, and I'm sure you'd be buying decent hardware for each node also whichever way you went. So they really aren't the deciders, whatever the paper may suggest.

For what it's worth, there's practically nothing in that paper which I don't freely admit to when teaching the 9i RAC course anyway. The issues raised are not trade secrets or something which Oracle hides: they're just something that someone who really needed clustering capabilities would have dealt with and prepared for anyway, whatever product they were going for.

Regards
HJR "Angie" <angie_kong_at_hotmail.com> wrote in message news:OWDE9.28936$hi6.3773_at_nwrddc02.gnilink.net...
> I was at Oracle World over a week back and got a free cup of coffee with
the
> following URL http://www.microsoft.com/sql/getmore which is mostly
> uninteresting marketing stuff. One thing that did catch my eye was the
paper
> on RAC http://www.microsoft.com/sql/evaluation/compare/oracle-rac.asp.
>
> Would appreciate your thoughts on this so that we may decide if we need to
> alter our 2003 plans. I know it's hard but please keep to the facts and
save
> the slams for another day (yes, we all enjoy them but please, not today,
> thanks). We use several databases apart from Oracle and biased opinions
> doesn't help us at all. Really appreciate your time on this.
>
> Thanks.
>
> --AK
>
>
Received on Tue Nov 26 2002 - 06:58:34 CST