IBM and Oracle have long touted their database systems' high availability. And CEOs and CIOs widely view these databases as absolutely reliable and ready for the enterprise. Unfortunately, SQL Server still seeks that assumption of absolute reliability.
Part of the problem is that SQL Server is the new kid in town. Oracle and IBM DB2 have been proven enterprise players for the past decade, while SQL Server has its roots in SQL Server 6.5, which some people still associate with small-scale departmental databases. With SQL Server 7.0, which boasted a totally retooled core database engine, SQL Server became ready for the enterprise. However, SQL Server still faces this perception of unreliability, linked to Windows' reputation (How many reboot jokes have you heard today?) and to all the press about Windows and SQL Server security exposures. (I know I cringed when I saw Oracle's "Unbreakable" ad in the trade press across from headlines about SQL Slammer causing widespread Internet outages.)
SQL Server's standing at the top of the Transaction Processing Performance Council's TPC-C rankings certainly boosts its enterprise reputation. However, the TPC-C is about performance. And although performance is certainly important, it's not the most important feature customers look for in an enterprise database. A recent study of enterprise database customers by Evans Data Corporation shows that reliability is the No. 1 priority. Total cost of ownership and the ability to integrate are next in line. And performance and scalability rank as fourth and fifth priorities, respectively.
Although ties to SQL Server 6.5's limitations will fade with time (and continued marketing), problems like the one the Slammer worm exposed will persist, despite Microsoft's diligence in product development. Interestingly, competing databases share many of the same security vulnerabilities. But those database systems don't share SQL Server's core problem: poor customer implementation (SQL Server Magazine readers excepted).
Companies install and manage Oracle and DB2 systems like "big iron"—putting a lot of effort, planning, and expense into implementing those systems and keeping them running. Under the same conditions, SQL Server's reliability is on par with the most highly available enterprise databases. However, SQL Server—far more than any other enterprise-level database—is installed and run under less-than-optimal conditions. We've all seen small business and departmental systems installed under someone's desk. One company I know of spent several hours trying to determine why its database was down only to find that the server, which had been sitting in a corner, had been turned off and moved into storage because someone thought it wasn't being used.
Reliability doesn't just happen. The base product's built-in availability features are only a starting point. From there, reliability is a consequence of good planning and best practices. Customers could easily have thwarted the Slammer fiasco, for example, if they had just closed their TCP/UDP ports, which never should have been open in the first place. For Microsoft's part, its biggest goal shouldn't be topping the latest TPC-C score. It should be instilling these best practices into its customer base.