RE: Documentation for reasons to NOT use RAC?
- From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
- To: <ahmusch@xxxxxxxxx>, <TESTAJ3@xxxxxxxxxxxxxx>
- Date: Mon, 22 Feb 2010 11:57:22 -0500
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: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Adam Musch
Sent: Monday, February 22, 2010 10:54 AM
To: TESTAJ3@xxxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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, <TESTAJ3@xxxxxxxxxxxxxx> 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
ahmusch@xxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
