Re: Documentation for reasons to NOT use RAC?
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: Freek.DHooge@xxxxxxxxx
- Date: Mon, 22 Feb 2010 13:19:19 +0000
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@xxxxxxxxx>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@xxxxxxxxx
> tel +32(0)3 451 23 82
> http://www.uptime.be
> disclaimer: www.uptime.be/disclaimer
>
>
> ________________________________________
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of TESTAJ3@xxxxxxxxxxxxxx
> Sent: maandag 22 februari 2010 13:52
> To: oracle-l@xxxxxxxxxxxxx
> 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"
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
