Re: RAC or Large SMP...?

From: DA Morgan <>
Date: Thu, 09 Oct 2008 22:56:05 -0700
Message-ID: <> wrote:

>> A large SMP machine will fail over to what? Another large SMP
>> machine of course. So you've bought two of them and one is idle,
>> sucking up overhead and electricity and doing essentially nothing.
>> And, of course, you had to buy a machine sized to handle your largest
>> workload which means it has a huge number of wasted cycles most
>> of the time.

> Fair point - I agree 100%
>> Now with RAC we have the initial overhead of training a couple of
>> DBAs. That should set you back less than $10,000 USD. Then you
>> buy inexpensive commodity servers, just enough to handle your needs
>> at the primary site, fewer for the secondary site, and within an
>> hour or two, at most, you can move nodes from one place to another
>> as needed so it doesn't matter.

> Another good advantage of RAC.
>> At Oracle OpenWorld in 2005 I built a 24 node cluster on the third
>> level of Moscone West. We had someone from Sun price it out using
>> SMP and RAC. The difference in price, for just one comparable SMP
>> machine as compared to our one RAC cluster was in excess of $250,000
>> USD. That pays for a lot of training.

> This is where I fail to see the benefit. That comparison was done
> against a Sun SMP box which would have been very expensive. Whereas
> we are considering IBM x3850's which have a list price somewhere
> around $25,000. Granted we would need at least 2 chassis for the
> primary and another 2 for the standby/spare but I imagine that the
> price difference between that and the equivalent RAC setup wouldn't be
> anywhere near $250,000.
> Did your price difference calculation take software/licensing into
> consideration or only hardware..?

Hardware, networking, storage, software licensing, everything.

Plus you get client and server side load balancing. Plus you get transparent failover.

I am not one that has had a long drink of the RAC is best for everything koolaid. There are situations where RAC is definitely not the best solution. But before one can choose wisely one must fully understand all aspects of the argument pro and con and all I am pointing out is that there are aspects not fully vetted in this thread.

 From my experience the financial argument will always favor RAC.

The performance argument may or may not favor RAC.

The single-point-of-failure argument will always favor RAC.

The simplicity argument will never favor RAC.

The flexible scaling argument will always favor RAC unless you have a zSeries server ... then it gets more complex.

Every solution has its strengths and weaknesses. You need to prioritize them based on your SLA and budget.

Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington (replace x with u to respond)
Puget Sound Oracle Users Group
Received on Fri Oct 10 2008 - 00:56:05 CDT

Original text of this message