Re: Oracle Standard Edition & RAC

On 1/4/07, Wolfgang Breitling <breitliw_at_centrexcc.com> wrote:
> At 05:44 PM 1/4/2007, Alex Gorbachev wrote:
> >A single node 4 CPU SE should scale even better than 2 node x 2 CPU SE
> >RAC so using SE RAC for scalability is luxury and company doing so has
> >way too much money.
>
> Am I missing something here? The Oracle licensing cost should be the
> same and 2 dual-cpu boxes should be cheaper than a quad. That's what
> RAC is for me: a beancounter's scalability solution.

Let's do the math. One machine that requires 4 CPU license is a 4 socket box with dual core Opteron CPUs. 8 cores with multiplier 0.5 give 4 CPU SE licenses. This is a non-RAC SE.

Two boxes each with 2 sockets and dual core Opteron CPUs (i.e. 4 cores each) will require 2 licenses per box. In the end we have to pay 4 CPU SE licenses as well.

Never say never but there are really very few cases when 2 node RAC with 4+4 cores would perform better than a single non-RAC 8 cores box. Maybe only when memory limit per box is hit.

Do I count licensing wrong way?

> I just can't buy the RAC HA argument. The only outage RAC protects
> you from is a server failure, not database failures due to human
> error or software bugs. And the probability of that (server failure)
> is probably only increased by running RAC with all its complexity.
> Quoting from a list of "unpleasant truths" published by Edsger
> Dijkstra in 1975! (from a recent post on the Oaktable network):
> Simplicity is prerequisite for reliability.

OK. Never say never, right? RAC does protect from single node failure and instance failure. Last night, one of our customer had one instance hanging absolutely dead in a 4 node cluster (surprisingly, all other nodes were just fine). Resolved by killing the instance and restarting it so no service outage. We can find plenty of other cases like shared pool fragmentation on one instance leading to termination or human error removing Oracle home (how many of you familiar with that).

Besides (and that's often forgotten or taken for granted), RAC allows many planned actions to be done with no impact. Examples - applying rolling patch, instance bounce for parameter change, OS patch, etc.

I'm not a RAC advocate for availability. I do agree that majority of the cases do not need RAC and, on the contrary, availability suffers as the consequence of increased complexity as you just mentioned. However, the right tool for the right job and there are implementations that take advantages of RAC features to improve service availability.

Just a thought about another scenario - I know some sites are using Extended Distance Clusters with RAC. In this case it supposed to protect in site disaster scenarios. I'm personally very careful and even skeptical about that and don't have experience with such clusters. Does someone have any first hands experience to share?

-- 
Best regards,
Alex Gorbachev

The Pythian Group
Sr. Oracle DBA

http://www.pythian.com/blogs/author/alex/
http://blog.oracloid.com
--
http://www.freelists.org/webpage/oracle-l