RE: Documentation for reasons to NOT use RAC?

From: Crisler, Jon <>
Date: Mon, 22 Feb 2010 11:57:22 -0500
Message-ID: <56211FD5795F8346A0719FEBC0DB0675060FE7F3_at_mds3aex08.USIEXCHANGE.COM>

Very good response and in line with what I was thinking. One of the first things you should do is calculate the extra cost of Oracle RAC licenses and implementation costs with the expected benefit. This usually shoots down about 50% of the proposed RAC projects as people are unfamiliar with the cost of RAC.

I disagree with some peoples position that RAC is not High Availability- it does address a lot of points (but not all) with server hardware and software availability, but machines are so reliable these days that if HA is the sole criteria there may be other more cost effective solutions. If almost-instant reconnection is required then RAC works, but frequently a 5-10 minute connection restoration is acceptable which then allows active / passive clusters to address the need (ala Veritas Cluster Server, RedHat Cluster Manager etc.). But unless you have Dataguard or some other storage replication method, it does not protect you from the classic "smoking hole in the ground" scenario.

RAC does not protect you much in the area of SAN faults- if you have redundant SAN switches and paths to your storage then some of it is addressed, but you will still have one disk farm.

If HA and DR is the goal, then you need to mix RAC with Dataguard, which is probably the ultimate resume addition for an Oracle DBA. It certainly works ok once you get past the learning curve. A less expensive alternative to RAC and Dataguard would be a Linux cluster made up of Veritas Cluster Server (VCS), VCS Oracle Agent and VCS Oracle Agent for Dataguard. Although an active / passive cluster, it gets around the Dataguard limitation of not supporting active / passive clusters.

If you must have RAC, then also consider Oracle RAC Standard Edition (as opposed to Enterprise). You cannot use Dataguard, parallel query, RMAN multiple disk streams etc. with this but it does get you RAC. Just make sure you can live without the certain features it omits- for large databases just the fact that RMAN is limited to a single stream can be a deal-breaker.

-----Original Message-----
From: [] On Behalf Of Adam Musch Sent: Monday, February 22, 2010 10:54 AM To:
Subject: Re: Documentation for reasons to NOT use RAC?

Compare the marginal cost of RAC for each systems to a realistic cost-of-downtime for each system -- include downtime for upgrades and server-level outages. My suspicion is that unless there's a hard-and-fast 24x7x365 availability requirement for a customer-facing revenue-generating system, RAC will be significantly more expensive than the alternative.

What's the cost differential between, say, an 8-core SMP machine with Oracle vs. 2 4-cores plus the marginal cost of RAC?

How much more is management willing to spend on human costs around RAC; RAC systems do require more effort to configure and manage; there's more stuff to do, and generally RAC-qualified DBAs cost more.

Also, a single-node RAC implementation will always be slower than a standard non-RAC implementation. Oracle's code path for single node RAC still has to go through all the global enqueue and global cache logic; the whole point of single-node RAC is to provide that sort of regresssion testing.

Even if RAC is free for all of your systems, it's still not free, and still not worth it.

On Mon, Feb 22, 2010 at 6:52 AM, <> wrote:
> 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"

Adam Musch

Received on Mon Feb 22 2010 - 10:57:22 CST

Original text of this message