Home » Server Options » RAC & Failsafe » RAC v. Data Guard (split from http://www.orafaq.com/forum/mv/msg/197950/639911/#msg_639911)
RAC v. Data Guard (split from http://www.orafaq.com/forum/mv/msg/197950/639911/#msg_639911) [message #641104] Mon, 10 August 2015 10:52 Go to next message
sybase46
Messages: 2
Registered: July 2014
Location: Northern Virginia
Junior Member
Been using databases with single instance and RAC. The only way I would ever use RAC is there would have to be a 1000% need for it! The ROI and extra ($$$) to include all the overhead a DBA has to do, it ain't worth it. I have yet to have a Single instance crash but continue having RAC node issues. Our Single Instance DBA have 10X the Oracle servers than our RAC DBA have, yet do 20% less troubleshooting. They actually do other DBA task such as Performance tuning ..e.t.c. Why companies got suckered into this is beyond me! Use data Guard/ standy wich will usally suffice. Mad

[Updated on: Mon, 10 August 2015 11:33] by Moderator

Report message to a moderator

Re: Convert Non RAC To RAC [message #641105 is a reply to message #641104] Mon, 10 August 2015 11:21 Go to previous messageGo to next message
Michel Cadot
Messages: 66650
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator

You cannot TAF with a standby database.
You cannot load balance with a standby database.

Re: Convert Non RAC To RAC [message #641106 is a reply to message #641105] Mon, 10 August 2015 11:29 Go to previous messageGo to next message
sybase46
Messages: 2
Registered: July 2014
Location: Northern Virginia
Junior Member
100% correct Michel. I was just refereing to a Failover. We are not using Load balancing as our VM are powerful enough. Sorry for not adding that caveat
Re: Convert Non RAC To RAC [message #641107 is a reply to message #641105] Mon, 10 August 2015 11:36 Go to previous messageGo to next message
John Watson
Messages: 8023
Registered: January 2010
Location: Global Village
Senior Member
Actually, you can use TAF between primary and standby: configure your tnsnames.ora alias with an address list that includes addresses for both, and specify sensible values for the retries and the delay. You do need to do tyhis if you are using DG Broker fast start failover, or your clients won't re-connect.
Re: RAC v. Data Guard (split from http://www.orafaq.com/forum/mv/msg/197950/639911/#msg_639911) [message #641108 is a reply to message #641104] Mon, 10 August 2015 11:39 Go to previous messageGo to next message
John Watson
Messages: 8023
Registered: January 2010
Location: Global Village
Senior Member
I disagree. Data Guard requries Enterprose Edition, $47.5 per core. RAC is free with Standard Edition, $17.5 per socket. OK, max four sockets in the cluster - but that is one heck of a lot of cores nowadays. And the fault tolerance is (in some ways) better than Data Guard, if you configure an extended cluster.

I split these messages off from the original topic, because it ewas bit of a hijack.

Re: RAC v. Data Guard (split from http://www.orafaq.com/forum/mv/msg/197950/639911/#msg_639911) [message #641274 is a reply to message #641104] Wed, 12 August 2015 15:13 Go to previous message
bpeasland
Messages: 51
Registered: February 2015
Location: United States
Member

sybase46 wrote on Mon, 10 August 2015 10:52
Our Single Instance DBA have 10X the Oracle servers than our RAC DBA have, yet do 20% less troubleshooting. They actually do other DBA task such as Performance tuning ..e.t.c.


Well as the saying goes....Your mileage may vary. Smile

I run both RAC and single-instance databases. I spend the majority of my time in the single-instance databases. My RAC databases don't require extra time that it seems your DBA's need to devote. There could be lots of reasons for our perception differences so I won't guess as to why we are different. But I would say that if my shop were experiencing situations as you describe, I'd take a look at the reasons *why*. Why are you experiencing more downtime for a RAC node than for a single-instance server. That shouldn't be the case and isn't the case for my RAC databases. Address the issues and fix them and things should improve.

Today's Oracle RAC databases are for three things. 1) availability 2) scalability and 3) consolidation. It seems like you're focusing on the first one, availability. There are other advantages as well. But if HA is the only driver for your company, then maybe RAC isn't the exact solution for you. You could explore Data Guard. You could explore virtualization HA techniques, like VMotion in VMWare.


Cheers,
Brian
Previous Topic: Oracle Service gets Stopped
Next Topic: Automatic failover in oracle 11g r2 (RAC 2 node)
Goto Forum:
  


Current Time: Mon Oct 21 23:10:34 CDT 2019