Re: Oracle Standard Edition & RAC
- From: "Alex Gorbachev" <gorbyx@xxxxxxxxx>
- To: "Wolfgang Breitling" <breitliw@xxxxxxxxxxxxx>
- Date: Thu, 4 Jan 2007 23:10:57 -0500
On 1/4/07, Wolfgang Breitling <breitliw@xxxxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
