RE: Documentation for reasons to NOT use RAC?
Date: Mon, 22 Feb 2010 11:55:27 -0600
Message-ID: <FD98CB0EE75EEA438CAF4DA2E6071C420564BACA_at_MAIL.solutionary.com>
Swimming against the current here, I respectfully disagree - in part. RAC can be a viable high availability option - if you truly need that level of HA (very few do). It is *not* a disaster recovery option, but I would draw a distinction between the two.
Consider these possible (and traditional) definitions. DR is the ability to survive the loss of the database, physical environment, power, connectivity, etc. - up to and including "everything". A "DR solution" could be anything from offsite storage of database backups that can be restored "somewhere else" to standby database(s) and beyond - depending on your tolerance for data loss and downtime. "High availability" could be defined as the ability to survive and quickly recover from node/instance failure - typically due to much more mundane and common events like RAM corruption, CPU failure, mainboard meltdown, etc. [The question for the latter is 'how high is "high"' - and the "solution" can be anything from "we have a spare server in a crate over in the corner" to an HA cluster to a standby database to RAC.]
For the latter, failover to a standby database may be costly overkill. IFF (intentional spelling) you need the ability to survive an instance failure with extremely little downtime and no data loss, have an application that is RAC-amenable and can justify the cost (perhaps with the inclusion of scalability advantages), then RAC _may_ be the best HA solution.
I've been doing OPS/RAC since 1996 and standby databases for about a decade. I agree that many (most?) OPS/RAC implementations have been done for the wrong reasons. This actually seems worse now that RAC has become more "mainstream". In the more distant past, any mention of OPS was routinely greeted with a garlic necklace and raised cross - not an entirely irrational response given the abundance of "poorly-conceived implementation" horror stories. Oddly enough, in some of my oldest experiences - with Oracle7 OPS at least - often the "wrong reason" was scalability! Some of the most successful Oracle7 OPS implementations I've seen were where the only benefit was HA!
If a standby database is sufficient for both DR and HA, then obviously RAC is not cost-justified for HA alone. However, there are cases where the difference between a 30-second brownout in a RAC cluster and failing *part* of the application (the part previously running on the failed instance/node) over to a surviving node is preferable to a (usually significantly) longer outage while switching everything over to a standby database. I have administered systems where such downtime costs were measures in (many) millions of dollars per hour and OPS/RAC literally saved the day - on more than one occasion..
Let the brickbats fly!
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Monday, February 22, 2010 10:07 AM To: cicciuxdba_at_gmail.com
Cc: Richard.Goulet_at_parexel.com; Hemant K Chitale; oracle-l_at_freelists.org Subject: Re: Documentation for reasons to NOT use RAC?
First and foremost, before you jump into this, make sure that your mission-critical applications are "certified" supported on RAC, and which version of RAC -- after all, a "RAC cluster" is ipso facto one version. That could be illuminating and show-stopping.
RAC is good technology, but it is a niche solution, not a general-purpose solution. It is not high-availability -- look toward Data Guard for viable database high-availability. It is a database scalability solution, plain and simple. If you cannot scale by moving to a larger server, then RAC is a viable alternative. Once the justification of RAC as a high-availability solution is removed (as it should be), then the decision of how to scale becomes a matter of which platform you are using. If you are on Solaris or HP-UX or AIX, chances are good you can scale quite high within a single server, without using RAC. If you are on Windows or Linux, chances are good you might have to use RAC. Crude generalizations, yes - but I'm being terse. Cost enters into it, as many IT departments do not want to buy/lease "big iron", but the Oracle licensing for RAC generally more than offsets, not to mention the hidden costs of training (formal or OJT).
I'm an OPS/RAC DBA since 1994, and the common trajectory for OPS/RAC implementations made for the wrong reasons (i.e. H/A not scalability, general-purpose not special-purpose, etc) often resembles Napoleon's retreat from Moscow.
Still, it's great technology, can be a lot of fun, and looks great on the resume.
Tim Gorman
consultant -> Evergreen Database Technologies, Inc. postal => P.O. Box 630791, Highlands Ranch CO 80163-0791 website => http://www.EvDBT.com/ email => Tim_at_EvDBT.com<mailto:Tim_at_EvDBT.com> mobile => +1-303-885-4526 fax => +1-303-484-3608 Lost Data? => http://www.ora600.be/ for info about DUDE...
Guillermo Alan Bort wrote:
Just make sure you don't end up having to manage 50 pointless RACs... ;)
Alan.-
On Mon, Feb 22, 2010 at 1:18 PM, Goulet, Richard <Richard.Goulet_at_parexel.com<mailto:Richard.Goulet_at_parexel.com>> wrote: Hemant,
That is quite true, but once you've voiced your concerns and objections (as someone else recently pointed out) your off the hook.
Dick Goulet
Senior Oracle DBA/NA Team Lead
PAREXEL International
-----Original Message-----
From: Hemant K Chitale [mailto:hkchital_at_singnet.com.sg<mailto:hkchital_at_singnet.com.sg>]
Sent: Monday, February 22, 2010 9:51 AM
To: Goulet, Richard
Cc: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
Subject: RE: Documentation for reasons to NOT use RAC?
Sometimes being politically correct can mean being professionally lacking. Lacking in management's duty to protecting shareholders (or citizen's) money.
At 10:35 PM Monday, Goulet, Richard wrote:
> Maybe the best argument for RAC is politics. .... It just makes
> your boss feel more secure.
>
>
>Dick Goulet
>Senior Oracle DBA/NA Team Lead
>PAREXEL International
>
Hemant K Chitale
http://hemantoracledba.blogspot.com
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Mon Feb 22 2010 - 11:55:27 CST