RE: RAC with one node as a DR solution

From: Ruel, Chris <>
Date: Tue, 4 Mar 2014 16:32:56 +0000
Message-ID: <>

I am not 100% sure I follow what you are trying to describe and also my definitions of DR may differ from you or others. In any case, here is my take:
  1. RAC is not a DR solution. I would categorize RAC as an HA (High Availability) solution. RAC protects you from node/isolated hardware failures with respect to HA.
  2. Solutions for DR from Oracle would certainly include Dataguard and some would even include Streams/Replication and GoldenGate.
  3. A DR solution implies that you have a separate system that is isolated (geographically separate) from the primary site to insulate from things like localized power outages, server room fire, or even a natural disaster that takes out a data center.
  4. While there is such thing as extended RAC (long distance nodes connected by dark fiber) you probably don't want to even consider that if cost is a concern of yours.

You know, if you are simply looking for a DR solution, I think Dataguard is probably your best bet. You do not have to pay for Active DataGuard (AD) to use regular Dataguard. However, Regular Dataguard requires that you license your remote site which can be expensive by itself...especially when you consider that w/o AD its usage is limited.

FWIW, one of the things I configured in the past used non-Active Dataguard. The client wanted to use the remote site for some things though. W/o AD, the only option really is to open the database read only to use it. When that occurs, of course, you fall behind keeping it up with the primary. Instead, we created two standby database on the remote server. One, we left in apply mode all the time for failover purposes. The other was opened (read/write) every morning at 8:00...used all day, then, closed at 8:00 PM, flashed back so archives could be applied from the primary and brought back up to speed so that when it opened at 8:00 AM the next day it was a fresh copy of the primary. Now, your business rules and needs may not support this sort of configuration but it was one way we were able to leverage our standby site for some usage while still staying protected and minimizing costs.

Another option for DR outside of Oracle is to use some sort of wide-area san mirroring...then, you could have Oracle installed at the remote site such that all you need to do is shutdown the primary and start it remotely. I think though that there is a lot of gray area in terms of licensing this configuration as you would probably want to periodically test it which would require starting the software stack. With RAC One Node, from my understanding, you have 10 calendar days per year that you can "activate" your secondary node without a licensing penalty (for things like maintenance, patches, etc.). Perhaps, you could use SAN mirroring with RAC One Node and avoid the cost of licensing your DR site. If a failure is detected on the primary node, The secondary node would start up. Personally, I have zero experience with a wide-area RAC One Node configuration...I am just theorizing a possible solution for you that might be worth looking into. Good luck!


Chris Ruel * Oracle Database Administrator<> * Desk:317.759.2172 * Cell 317.523.8482

From: [] On Behalf Of Chris King Sent: Tuesday, March 04, 2014 10:45 AM
Subject: RAC with one node as a DR solution

I'm considering a two-node RAC for a new production environment. For the DR, I'd hoped to use active data guard, but it's very expensive. I've avoided the architectural option of adding a third node, but locating it in the DR environment, because the network to DR will be slower.

Is there a way to set up 3-node RAC, with one node as DR, such that the node in DR can be set to NOT hold up the other two nodes due to any network latency?

The node in DR would not have to be up to the minute. It would be acceptable to be up to 30 minutes behind.

Thanks in advance for your feedback!

Notice of Confidentiality: **This E-mail and any of its attachments may contain Lincoln National Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Lincoln National Corporation family of companies. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Thank You.**

Received on Tue Mar 04 2014 - 17:32:56 CET

Original text of this message