Reading Oracle’s technical whitepaper, Oracle Real Application Clusters 11g Technical Comparison with Microsoft SQL Server 2008 [1], located here, one does readily see that the gap between Oracle and SQL Server in this department is growing wider with each release. The paper reviews Oracle technologies with respect to four key areas of SQL Server for scalability and availability: 1) Federation servers, 2) Clustering, 3) Mirroring, and 4) Peer-to-peer replication. In each, a fair and complete synopsis of comparative features clearly shows that we’re losing this battle now as much or more than ever.
If you are familiar with these technologies (I have used and administered all in a production setting), you understand that they don’t exaggerate:
Federation Servers – I never liked these anyway, right from the get-go. Distributed partitioned views using constraints to segment data sounded like a bad idea when I first heard about it in SQL Server 2000, and still does. This technology clearly lacked any type of ability to partition workloads after it was set up; it was possible for one server to go crazy trying to fulfill requests to the database while others were idle. And, there was no way to monitor this. Any type of horizontal or vertical partitioning of SQL Server is weak technology in my opinion. Moreover, anything relying on the MSDTC is a problem; this is a technology that, according to a resource of mine on the SQL engine team, has not had any significant development the last 10 years. How good can it be? The aforementioned article completely rips Federated Servers to shreds, and rightly so.
Clustering – A decent technology for availability, but no scalability. Limited number of nodes as well. Relies on network and O/S, not instantaneous. Requires much specialized hardware, setup, etc. Not a scalability solution, this could easily be replaced by Mirroring in the near future as it becomes increasingly robust.
Mirroring – Limited to one server. A good technology, not seamless if you have to actually revert to a mirrored server if production breaks. Availability, again, with no scalability. Can be good when used in combination with other solutions, but again…more setup and administration.
Peer-to-Peer – Really like this a lot, and have a nice blog in the works on this based on some of my testing of P2P replication. Great technology and could prove to be the foundation for true scale-out one day for SQL Server. The problems here: 1) multiple copies of the database are required, 2) limited conflict resolution, and 3) still requires either changes to the application or provisioning within database tables (manipulating identity attribute, primary keys, etc.) for instance.
Not a pretty picture. And I believe that Microsoft knows this – “under wraps” in Redmond is a project in full swing to address SQL Server’s shared-nothing architecture for a shared-something approach. What does this mean? Essentially, SQL Server operates as a stand-alone entity with regards to scalability. The only way to get more processing power is to get a more powerful box. Sure, homespun and custom architectures are possible with the product to scale out, yet none are as seamless as Oracle has, and require either changes to the application, database structure, network, or any combination thereof to scale out. Each requires a degree of setup and programming time, and are not officially supported by Microsoft needless to say. So, because of this architecture, combining the power of one, two, four, or one hundred boxes is not available in SQL Server. Integration of a single database across nodes is not possible. Moreover, virtualizing processing power, RAM, etc. as can be done with Teradata, a key component to using multiple machines housing various types of databases (OLAP, OLTP, etc.) responding to various types of user requests, is very far in the distant future for SQL Server.
Hopefully you don’t think that I am exaggerating here – Otey [2] from SQL Server Magazine writes…
In planning features for the next release, the SQL Server team will certainly need to work hard on clustering. Oracle 10g offers easy clustering for scalability, a feature that the current release of SQL Server doesn't have an answer for. The difference in clustering technologies makes this a tough nut to crack for Microsoft. Oracle uses a shared storage approach to clustering that's easy to manage but has scalability limits—a problem for high-end deployments but not for smaller two-to-four system clusters that appeal to mid-sized businesses. Microsoft has gone the opposite route, adopting a shared nothing clustering strategy that has no high-end scalability limits but is difficult to manage and requires intimate, advanced database knowledge to successfully implement. Coming up with a better clustering solution, especially for mid-sized businesses has to be a priority for Microsoft with the next release of SQL Server.
Unfortunately, we’re already past that “next release”. Let’s hope that this initiative now underway begins to make some headway.
Lee
-----------------------------------------------------
“Oracle article”. Try saying that fast ten times.
References
[1] Technical Comparison with Microsoft SQL Server 2008 - An Oracle Competitive White Paper. Retrieved on 3/28/2009 from http://www.oracle.com/technology/products/database/clustering/pdf/twp_racsqlserver_2008.pdf
[2] Otey, Michael. What’s next for SQL Server [sic]. Retrieved on 3/29/2009 from http://www.sqlmag.com/Article/ArticleID/48821/Whats_Next_for_SQL_Server.html