Oracle RAC vs. SQL Server AG

As I have seen the benefit for having a post on Oracle database vs. SQL Server architecture, let’s move onto the next frontier- High Availability…or what people think is high availability architecture in the two platforms.

To RAC or Not to RAC

There is a constant rumble among Oracle DBAs- either all-in for Oracle Real Application Cluster, (RAC) or a desire to use it for the tool it was technically intended for. Oracle RAC can be very enticing- complex and feature rich, its the standard for engineered systems, such as Oracle Exadata and even the Oracle Data Appliance, (ODA). Newer implementation features, such as Oracle RAC One-Node offered even greater flexibility in the design of Oracle environments, but we need to also discuss what it isn’t- Oracle RAC is not a Disaster Recovery solution.

Disaster Recovery projects hold requirements for secondary, failover environments to be housed in a second data center or cloud and multiple databases, but that simply isn’t what Oracle RAC is. That doesn’t mean we can’t build out the solution, it just means, in our comparison to grant an Apple-to-Apple comparison, I’m going to add a second product into the scenario- Oracle Data Guard.

RAC on Azure VMs

For those trying to build out Oracle RAC on Azure, yes you can do it. You can build out a VM cluster and then use FlashGrid underneath the Oracle RAC installation. Would you want to do it? I just don’t know why. If you ask the customer questions, so far, every time, I’ve discovered a better way to reach the solution they are hoping to achieve and it didn’t involve RAC. It was quickly discovered that just because you needed something on premises, bringing in the cloud changes everything. Redundancy is built into the infrastructure, VMs can have clustering built in and I would prefer to put Oracle Data Guard on a VM over implementing all the moving parts with RAC.

So what is Oracle RAC bringing to the game?

Now to directly discuss Oracle RAC with Data Guard comparison to SQL Server Always-on Availability Groups:

Note that Oracle RAC has numerous nodes that are connected to one RAC database. This database seamlessly connects to all sessions, directed across the nodes by the Scan Listener. Transactions, including Undo and Redo is shipped between the nodes via the Global Cache.

In our architecture, we’ve added in Oracle Data Guard, which is a secondary replica that can then be sync’d with the archive logs, (similar to transaction logs in SQL Server) and can be made use of even more if implementing Active Data Guard.

For SQL Server Always-on Availability Groups, the architecture above has implemented a primary with two replicas, one on-premises and a secondary in a remote data center, providing full DR in case of the primary data center being unavailable. Note that there is no write to the replicas back to the primary. They are solely isolated and designed for High Availability and Disaster Recovery.

When talking scalability, Oracle RAC allows the DBA to allocate more hosts to allocate more CPU and memory to a given database. The amount of nodes that can be allocated to a unique database is quite extensive, where in SQL Server AG, each node requires storage for its unique replica that must be provisioned along with the CPU and memory resources.

The Gist

So high level, it’s good to remember the following:

I know I didn’t get in too deep with any of the technology here, but that wasn’t my goal. I wanted to try to give everyone, no matter which platform you specialize in, to see the other side of what is similar. Hopefully this helps.