A little bit far from what Microsoft says in this paper WhyNotOracleRAC (What a title!).
Executive summary goes to the point: almost nobody uses RAC because it is expensive and complex to mantain, deploy and troubleshoot...
Instead MS states that "the Microsoft® SQL Server® database program represents a wiser investment because it can meet the same requirements as an equivalent Oracle RAC installation at a much lower cost" with an SMP (simetric multi-processing) approach, that is, powerful CPUs with lots of cores...
First comments:
-MS mostly resigns the way of paralelism based on separated machines... perhaps a correct decission nowadays but who knows tomorrow, it doesn't seem very wise to leave this door closed.
-In the Active/Pasive Cluster scenario (most used in SQL-Server) you would have one of you nodes, "stopped", without taking profit of it (and somebody would say, who cares!, moreover if in the end you get more for less...).
I have read here with surprise that Oracle doesn´t scale well in OLTP system (large amount of updates)... and that it does even worst in OLAP/Data Warehouse due to the payload required for state sync among cluster´s nodes...!!!
That is, if you trust MS, RAC, besides being expensive and complex, won't provide the benefits it's supposed it offers (the highest processing power). They also talk about an independt study who demonstrates that RAC doesn`t provide linear scaling, and that in order to get a real profit of it, you have to code your applications in a very particular manner in order to fit in the RAC architecture and avoiding to fall in worse performamce results than you would get in a more common deploying architecture.
Another thing to take into account is the failover recovery times when a node of the cluster fails:
Technology Recovery time (approximate)
- Oracle RAC 30 – 60 seconds
- SQL Server Database Mirroring <45 seconds
- SQL Server Failover Clustering Minutes
Oracle: Surprise, surprise, there are also recovery times affecting the whole system in RAC: first for detecting the failing node, readjust parameters for the remaining ones, cleaning up all the hanged DB stuff that was being procesed on the failed node...
Also would be a mistake to suppose that RAC's load balancing capabilities are enough to isolate trasnparently your application from a failure of one of the nodes. The real stuff is that you still have to manage it in your application if you want to prevent users to notice this situations (not without little effort).
Anyway, recovery time for SQL Serer in Failover Clustering (minutes) are neither very attractive (and as said, it is the most common way to gain fault tolerance with SQL-Server beacuse of simplicity and security of data integrity).
That is, in general we can say that RAC beats MS in this point.
Finally:
It would be nice to read an Oracle's paper talking from te opposite side of the river, telling funny things about Redmon's guys. Perhaps this paper doesn`t exist, who cares in Oracle about SQL-Server.... ;)?
And, as you know, there are lots of aspects and features to take into account when deciding wich will be the better DB solution for an organization...
