Re: Oracle RAC cost justification?

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?

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've got my own ideas as to the answers to these questions, and I'd be glad to share them:

    Q1: When is RAC the best solution for scalability?

    Tim-A1:

        When you can't buy a larger server.

• The largest Linux server of which I'm aware is 8 CPUs. I'm not sure on this, though...
• The largest Windows server of which I'm personally aware is also 8 CPUs, but I've heard that Win2003 can support up to 64 CPUs?
• For AIX, the largest server is 32 CPUs...
• For Solaris, the largest server is 144 CPUs...
• For HP-UX, the largest server is (I think) 128 or 256 CPUs...

        Of course, these are constantly shifting numbers;  if I'm
        wrong on any of these, my apologies in advance...

        Anything larger can only be accomplished by RAC.  Anything less
        scales better without RAC.  So, RAC as a scalability solution
        is a platform-dependent choice, also dependent on your needs.

    Q2: When is RAC the best solution for HA?

    Tim-A2:

• For unplanned server or instance outages (a.k.a. "failure"), RAC (when running in an active-passive configuration) has the fastest service failover of all options. When RAC is running in an active-active configuration, service failover takes somewhat longer, possibly as long as other HA alternatives. However, persistent connections using "transparent application failover" (TAF) are an attractive possibility, though TAF must be configured intelligently (i.e. commonly recommended config does not support "failback") and has many restrictions (i.e. PL/SQL package state does not failover, DML does not failover, etc)
• For planned server or instance outages (a.k.a. "maintenance"), RAC is not the very best HA alternative; OS clustering packages (i.e. Veritas, Sun HA, HP MCSG, AIX HACMP, etc) are more robust
• For planned or unplanned storage or data center outages (a.k.a. disaster recovery), RAC does not (at this time) fit in this discussion

On the cost-effectiveness question, I've run out of time (and energy) for one response...

What do y'all think?

-Tim

on 6/1/05 8:33 PM, Khemmanivanh, Somckit at somckit.khemmanivanh_at_weyerhaeuser.com wrote:

> Whoa, a SAN is non-redundant???
> =20
> I agree it could still be a SPOF but it certainly is redundant component =
> wise...
> =20
> I guess you're entitled to your opinion regarding rather RAC provides HA =
> for the Oracle Instance or not. Keyword here is Instance. RAC provides =
> HA at the Oracle instance, that does not exclude you from addressing the =
> other SPOFs in your environment (to what degree your budget =
> allows)...but if 1 instance in the RAC cluster should go down, there =
> should be others available to handle the workload...
> =20
> My definition HA for the Oracle instance is really just that there is =
> minimal downtime should 1 instance in the RAC cluster be unavailable. =
> What does any other HA clustering solution provide? It simply restarts =
> the Oracle instance on the standby node...
> =20
> If you have a different definition of HA, well that maybe that's where =
> we're miscommunicating...=20
> =20
>
> ________________________________
>
> From: Jared Still [mailto:jkstill_at_gmail.com]
> Sent: Wed 6/1/2005 5:18 PM
> To: Khemmanivanh, Somckit
> Cc: oracle-l_at_freelists.org
> Subject: Re: Oracle RAC cost justification?
>
>
> HA for the Oracle Instance?
>
> You're kidding, right?
>
> If you have SPOF, it isn't HA.
>
> A non-dedundant disk system is a rather glaring SPOF.
>
>
> On 6/2/05, Khemmanivanh, Somckit <somckit.khemmanivanh_at_weyerhaeuser.com> =
> wrote:=20
>
> Well RAC is not the SAN right? RAC is HA for the Oracle Instance.
> =20
> If you're saying the total HA solution involves eliminating all SPOFs, =
> I'd agree but cost is always a limiting factor in that regard...
> =20
>
> Thanks!=20
>
> =20
>
> ________________________________
>
> From: Jared Still [mailto:jkstill_at_gmail.com]=20
> Sent: Wednesday, June 01, 2005 4:04 PM
> To: Khemmanivanh, Somckit
> Cc: Vlado Barun; oracle-l_at_freelists.org
> Subject: Re: Oracle RAC cost justification?
> =09
> =09
> =09
>
> On 6/1/05, Khemmanivanh, Somckit =
> <somckit.khemmanivanh_at_weyerhaeuser.com> wrote:=20
>
>
> Let's say we already have Service Guard in house. For new
> implementations should we go with MCSG or look at RAC? RAC is an HA =
> and
> scalability solution (MCSG is purely HA). I'm trying to get a good
> =09
>
>
> RAC might be many things, but HA is not one of them.
> =09
> The disk subsystem is a single point of failure: you only have one =
> database.

--
http://www.freelists.org/webpage/oracle-l