Re: Feedback on please

"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

Hi Angie,

A few points:

This is a *Marketing Messages* paper from Microsoft, no more. And with most marketing papers, it's full of bias and half truths. Have you *ever* read anything from Microsoft that says " and in conclusion, Oracle's product is much stronger than ours and we strongly recommend purchasing Oracle". Me neither (nor have I read any such thing from Oracle the other way round either).

They briefly mention that SS implements scale out "by federating a group of independent databases" as if this was some kinda benefit. It isn't and it is a key difference between the two, especially with respect to applications written in such an environment. I would strongly recommend researching this point thoroughly.

On the issue of scalability. One mega box has advantages over several clustered "smaller" boxes as it's always going to be advantages to have data cached "locally". I don't believe Oracle claims otherwise. However, if your current server is insufficient and you need to move on to the newest mega box, that's a significant cost. If you could attach a new node and increase your capacity that way, you can scale up at substantially less cost. A point not made in the paper. Also 9i Rel has substantially reduced the "messages" required with RAC. I would strongly recommend talking to Oracle (and hardware vendor) regarding the number of nodes that can be clustered and the amount of overhead associated with any such arrangement. The "sweet spot" has significantly increased since Oracle World 2001.

On the issue of High Availability. The issue of applying patches is a notable point. However, the "obvious" advantage of having several machines rather than the one single point of failure could have done with a bit more of a mention I would have thought. Especially as the features available with RAC Guard were not really mentioned.

On the issue of Cost. A 2 x 8 CPU 16 GB RAM vs 2 x 4 CPU 8 GB RAM where 8 CPU 16 GB configuration is a must. A bit of a non brainer really and a somewhat strange example. What about a 3 x 4CPU 8 GB RAM configuration or a 4 x 2 CPU 4 GB RAM configuration, etc. The loss of one node would mean the remaining nodes having to take on the extra load but if configured appropriately this may not be such an issue ? Having RAC does not mean having to cluster nodes that are required independently.

I do agree that the published Oracle costs of RAC licensing is high, probably too high. However, when comparing costs, it's important to compare objectively. We are not necessarily comparing apples with apples here. Also, if you approach Oracle and say, "sorry, but your pricing is too high, we have to go elsewhere" I would strongly suspect a discounted offer coming your way. It's the way it works ;)

My recommendation would be to be really careful with marketing material (from any organisation). I would recommend speaking to some *technical* (pre)sales folks at Oracle (and MS and anywhere else of interest) and get them to give you some *facts* and some *reference sites* and perform a cost/benefit analysis and make an educated decision.

I'm soon to be involved in a rather large Oracle RAC project so I guess I'll so find out what's what !!

Cheers

Richard

>
>
Received on Tue Nov 26 2002 - 07:38:54 CST