There are two main reasons for using an Oracle RAC. A shared, ‘multi-tenant’ environment which scales seamlessly to increasing load. And a high-availability cluser which provides a redundant node (or nodes) in the event of failure.

 If you are interested in having a large SHARED memory pool that can host multiple tenants (multiple apps), then SQL Server Enterprise can provide you with that memory pool. The maximum memory for SQL Server Enterprise is the OS max – which is 4TB for a Server 2012 OS. For SQL Server Standard, the max limit is 128 GB – which may still be enough to provide a multi-tenant environment.

If you are concerened with High Availability – and less with multi-tenant hosting, SQL Server Always On Availability Groups (AoAG) come close to the availability and scalability of RAC.  

One can scale out reads by querying against the mirrors, but  all DML needs to be directed at the primary server (SQL Server mirrors are read only and not updateable). If the primary SQL Server crashes, failover to one of the mirrors is near instantaneous. RAC experiences a similar pause if a node crashes as uncommitted transactions on the failed node are rolled back.

Load balancing through Replication – The only direct relation between replication and load balancing is that you need some replication to be able to load balance, else you’d have a single server.

Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

Initial Consultation

Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

 Twitter Linkedin