Re: Ho hum
"Plenty of places use it. If you can afford Oracle RAC then array replication licensing probably isn't a cost issue.."
Very few Oracle DBs use RAC in the first place. Of those that use RAC, the vast majority have a cluster (usually three servers) writing to a storage array at site one, data guard shipping logs to site two for failover. Generally async as it is a free license and people are concerned about passing corruptions. Exceptionally few use Extended RAC across two data centers for HA with a third environment (could be in the same second data center or not) for DR.
"It doesn't if you don't want it to. There are multiple ways of designing RAC with no single point of failure. Depending on your budget RPO and RTO."
You would synchronously replicate it, if that is what you mean. Avoids the SPOF, but creates the performance bottleneck described below.
"No you don't. Please leave this stuff to people who understand how to do it right! If you also want to have fast recovery from replicated storage corruption (never seen it with Oracle, but technically it could happen) then you say use Dataguard and ship logs to 2 target servers - one in each DC"
That's probably why I wrote "some third environment for DR" and not a third site, necessarily... although you might want a third site as the two synchronous sites have to be within maybe 20-30 miles of each other and a DR site should probably not be in the same area as the primary. Adding a third set of hardware still adds cost, even if there are three sets (storage devices) in two data centers.
The real issue though, as I wrote and you did not address, is performance. If you need to keep two mirrors across some sync distance in perfect harmony. You would have to have cluster A write to primary storage A, primary storage A sync replicate that write across a network to storage at site B... then start the next write. So anytime you alter the DB tables, you need to write to primary, replicate that write across a 20 mile network or whatever to storage B, have storage B send the acknowledge to storage A that it did, indeed, complete the write... then the DBs can start on the next write. That is a massive bottleneck if you are trying to run a massive throughput operation.
Biting the hand that feeds IT
