Re: Documentation for reasons to NOT use RAC?

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Mon, 22 Feb 2010 13:19:19 +0000
Message-ID: <7765c8971002220519y5b5896a9kae9b260f647beae8_at_mail.gmail.com>

Well Mogens Norgaard wrote a paper on this way back in the 9i timeframe which still makes a lot of sensible points. The paper is called "you probably don't need RAC" and googling for it will find a number of copies. There are some statements in it that are no longer correct - for example rolling upgrades have actually been delivered in some circumstances now - but I'd still say that it makes a lot of sensible points. Mogens also writes a little about some of the political and psychological issues that you might encounter at
http://wedonotuse.blogspot.com/2006/11/brief-intro-to-marketing-or-you-need.html.

I'd say that RAC is a great scalability product - so if you have applications that you have insufficiently powerfu hardware to run - then it's an excellent fit, of course many databases don't even stress 2-cpu pizza boxes these days, especially if the pizza boxes are stuffed with the extra hot chilli versions - er I mean things like the current dl360s from HP with decent san connectivity and excellent CPU power.

In addition RAC is sold as an availability solution. It isn't. You still have only one db, making it run on two bits of kit doesn't make it more available for any of the important failure modes (human error, application error) and in fact make at least the first of these more rather than less likely.

Still RAC is good to have on your CV and likely to promote job-security so maybe you should just learn to love it :)

On Mon, Feb 22, 2010 at 1:02 PM, D'Hooge Freek <Freek.DHooge_at_uptime.be>wrote:

> Following reasons springs to mind:
>
> . Rac costs money. Not only for the licenses, but it also costs more time
> to maintain them (patching and stuff) and you need more experienced dba's to
> operate them (otherwise you would have more downtime due to human errors).
>
> . Not all applications benefit from RAC, both in terms of high availability
> and scalability. If you have for instance an application which mainly
> focuses on 1 table (and doing full table scans on it), it will not scale on
> RAC.
> Also, when your application can not cope with sessions being disconnected
> and restart on a different node (eg no support for fcf), then the high
> availability will be limited.
>
> . The database is just not important
>
>
> Regards,
>
> Freek D'Hooge
> Uptime
> Oracle Database Administrator
> email: freek.dhooge_at_uptime.be
> tel +32(0)3 451 23 82
> http://www.uptime.be
> disclaimer: www.uptime.be/disclaimer
>
>
> ________________________________________
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of TESTAJ3_at_nationwide.com
> Sent: maandag 22 februari 2010 13:52
> To: oracle-l_at_freelists.org
> Subject: Documentation for reasons to NOT use RAC?
>
>
> I'm being pulled into a meeting later this morning to answer why we
> shouldn't put every db in RAC? Any white papers etc, stating why its a bad
> idea?
>
> thanks, joe
>
> _______________________________________
> Joe Testa, Oracle Certified Professional
> Senior Engineering & Administration Lead
> (Work) 614-677-1668
> (Cell) 614-312-6715
>
> Interested in helping out your marriage?
> Ask me about "Weekend to Remember"
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

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

Received on Mon Feb 22 2010 - 07:19:19 CST