Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle RAC cost justification?

RE: Oracle RAC cost justification?

From: Marquez, Chris <cmarquez_at_collegeboard.org>
Date: Thu, 2 Jun 2005 14:33:57 -0400
Message-ID: <B30C2483766F9342B6AEF108833CC84E0450BBF1@ecogenemld50.Org.Collegeboard.local> 





"Oracle RAC cost justification?"


It not hard to justify the COST once the NEED is justified.
---REGARDING COST:



>> "RAC and a cost effective solution is an oxymoron."

There is some truth to this too, but lets be fair.
RAC was once only for those with multi-million dollar budgets and few DBA's could even put their hands on RAC (aka OPS).
Today, that is not true.  Not to start a Oracle License flame but this doc was recently posted on this list.
RAC is *included* for 10g SE & SE One!?


  Oracle Database 10g Product Family An Oracle White Paper
  Jan. 2004


  ...


  Feature/Option:  Oracle Real Application Clusters
  SE & SEO: Y



  EE: Y


  Notes: Extra cost with Enterprise Edition, included with SE, not in SE One



PS RAC is listed as a "Scalability" option and *not* "High Availability" in this doc!...but I disagree. ;o)




---REGARDING NEED:



Mogens Nørgaard's document and Tim Gorman post are great regarding the need and use of RAC.



"You Probably Don’t Need RAC" is probably one of the best and "right on" docs about RAC and the history of Oracle Clusters (OPS) I howave ever seen.  However, I think the doc is lacking in two ways.
While the author (Mogens Nørgaard) gives much (deserved) credit to developers Oracle Cluster technology he under plays one significant and key change that makes OPS, not RAC.
The ability to complete WRITE-WRITE instance transactions in Cache Fusion.  Most people are surprised, as was I, when I found out that "Cache Fusion" existed in 8i.
The problem is that until Oracle Cluster technology overcame the ability for all nodes to WRITE-share-WRITE the same block without writing it to disk *first* (a PING) OPS was just not practical nor scalable.
Without this (cache) WRITE-WRITE ability, we would not even be discussing RAC here today.



What I like to call "The RAC Reality" stated by Oracle;
"if *your* application will not scale by adding CPU on a single server, it will not scale on RAC"
This is a fact than many developer/managers don't know (or don't want to hear.)



I have worked with OPS/RAC since Oracle 7.  It is a cool technology and has very particle uses and I would continue to use and recommend it.
However, I personally feel that whether it is Oracle's fault or applications fault, RAC never lives up to the usability (running active-active, TAF, etc.) expectations.
For the 3 clients I worked, who use RAC/OPS they all been, in the end, only able to use and benefit from RAC using it in "Failover Mode" ("active-passive").
Meaning all end user sessions run from single instance at any one time.  Should that instance die/fail/terminate we "Failover" to the other "passive" instance.
Again many reasons for this...most are technical issues that lead to political issues.  After the political issues, no one including the DBA's are willing and want to "stand behind" RAC and running in full RAC "active-active" mode.
Even the savvy RAC newbiess starting asking "why do we have "global cache" waits now?" :o|



Also, I must admit that I have see as many OPS/RAC successes, as I have seen failures.
I have seen cluster and OPS/RAC hangs the *cause* the downtime...as many times as I have seen downtime reduced by RAC/OPS during the loss of a node.
It just tends to be that the loss of a node/server is a longer outage and thus OPS/RAC pays off...but trust me it is not a good feeling being in a "day after meeting" explaining that OPS/RAC hang *caused* an application outage!
Enough of these meetings and week long TAR's and you will run in RAC "Failover" or "active-passive" Mode too!




---REGARDING SCALABILITY:



I have mixed feeling on this, but no technical data to support my ideas...so I wont spew them.
However, to be fair RAC has a missed scalability, or rather administrative benefit.
You can reduce the number a databases and "application glue" with RAC.
Simply, I can join databases that once used Snapshots, into a single database and run different user groups on different instances.  I just reduced my database liability and administration by one, AND eliminated the distributed nature of my database app.  "Application Partitioning" is not a bad thing in a centralized world!




---REGARDING HA



>> My definition HA...

>> you have a different definition of HA

>> well that maybe that's where we're miscommunicating




If a "single point of failure" is the *rule* for all HA, then true HA can never be achieved...as the plan Earth is a "single point of failure".
I personally believe that if you have adequate redundancy, then you have some (solid) level of HA.
I find when talking with groups of people its best to discuss two topics; "HA" and "Disaster Recovery", rather than just one.
To me HA is the ability to recover from a failure..."having redundancy".
And Disaster Recovery is the ability to recover from a true catastrophic disaster, "loss of all redundancy".



Think about it, RAID keeps the "system" running in the event of a failure...redundant support.
While are "system backups" saves us from a disaster such as loss of all redundancy.



IMHO, HA is the *active* use of redundant resources...while Disaster Recovery is *passive* use duplicate resources.  RAC for me is HA...as I have seen it work that way.




---REGARDING & DBA's


>>so getting a RAC implementation on your project 

>>helps you get your next job.




There is some truth to that! :o|




This is a good topic and conversation.




Chris Marquez


Oracle DBA





-----Original Message-----


From: oracle-l-bounce_at_freelists.org on behalf of Tim Gorman
Sent: Thu 6/2/2005 12:24 PM


To: oracle-l_at_freelists.org


Subject: 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:






Q2 - RAC and scalability:






Q3 - RAC and cost-effectiveness:






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.





        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:





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




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


Received on Thu Jun 02 2005 - 14:41:47 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US