Re: Oracle RAC cost justification?
- From: Tim Gorman <tim@xxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 02 Jun 2005 22:56:02 -0600
SMP (a.k.a. "symmetric multiprocessing") actually exists in only one
platform -- IBM. That's why it only scales to 32 CPUs, because the problem
is connections. You can only connect so many CPUs to the same memory. But
they are all "equi-distant" from any address in memory.
Other platforms are actually closer to what used to be called NUMA (a.k.a.
"non-uniform memory access"), because CPUs and RAM are clustered together on
boards that communicate over a bus, thus causing some memory to be "closer"
to some CPUs than other. If a CPU wants info from memory address XXX, then
perhaps that is available on the same board, no need to go over the bus.
However, if that same CPU wants info from memory address YYY, then perhaps
that is on another board, so we have to go across the bus to the other
board. Sun and HP architectures fall into this category, even though both
are commonly referred to as "SMP" as well.
So, you are correct that scaling does not occur linearly in such NUMA
architectures. Most likely it does not occur in "true SMP" architectures
either. But I don't think that there is any argument that either SMP or
NUMA scales much more effectively than RAC/OPS, is there?
Thus, you are correct that RAC/OPS has a place. Less on platforms like Sun,
HP, and IBM than on platforms like Linux and Windows, though...
on 6/2/05 7:38 PM, David at thump@xxxxxxxxxxxxxxxx wrote:
> SMP machines don't scale in a linear fashion after a certain numbers of
> CPU's(Long ago I was told 14). That is why I was lead to believe
> MPP/RAC/OPS/RAC/Grid/Mesh was introduced.
>
> With the right design it made and makes perfect sense.
>
> Alas, Oracle has revamped it and marketed as in a way that makes execs go,
> wow cheap solution to big expensive SMP machines...well there are holes in
> that cheese.
>
> It has it's place...just not many.
> David
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of Niall Litchfield
> Sent: Thursday, June 02, 2005 1:40 PM
> To: tim@xxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Oracle RAC cost justification?
>
>
> Hi Tim
> On 6/2/05, Tim Gorman <tim@xxxxxxxxx> wrote:
>
>> Instead of arguing about whether RAC is good at scalability or HA or
>> cost-effectiveness, how about citing specifics?
>>
>> Q1 - RAC and HA:
>>
>> - What does RAC do better than any other possible solution (i.e. OS
>> clustering, DataGuard, volume replication, etc)? How and why?
>> - What other solutions are better than RAC at HA and why?
> I'd argue that any solution that breaks the single location, single
> database requirement of RAC will give better HA.
> Q2 - RAC and scalability:
>
> - When does RAC present a better scalability solution than, say, simply
> buying a larger server?
> - What scalability bottlenecks does a RAC solution resolve better than
> alternatives (i.e. larger server, RAM disk, etc)?
> - What other solutions are better than RAC at scalability and why?
>
> Q3 - RAC and cost-effectiveness:
>
> - Compare and contrast the explicit (and implicit) costs to a RAC versus
> non-RAC configuration for the following scenarios:
>
> * 8 CPUs of processing capacity required, no HA reqmts stated
> * 8 CPUs of processing capacity required, MTTR less than 1 hour
> * same as above for 64 CPUS of processing capacity
> I'd link those two. Implicit in your question seems to be the ideas that
> a) you can satisfy your demand with a known number of CPUs
> and
> b) you already have that demand.
> I see RAC as being a killer app for folk who *right now* need say 2 or 4
> cpus but may well need 8,16 or 32 as business takes off. If you go the
> single instance route then what do you do, buy four times as much hardware
> as you currently need just in case? In addition for people who don't know
> what their cpu and memory requirements actually are RAC might well make
> sense. (or they have platform limitations about how much hardware their os
> can sensibly address on a given node.) If i'm right the bundling of RAC with
>
> SE in 10g makes a huge amount of sense.
> as for cost-effectiveness, as i was trying probably imperfectly to say,
> make sure you are comparing different solutions to the same business
> problem.
>
--
//www.freelists.org/webpage/oracle-l
Other related posts: