The SQL Server Scapegoat
I'd like to add to Michael Otey's excellent comments in his Editorial "Reliability Doesn't Just Happen" (September 2003, InstantDoc ID 39661). In the article, Otey explains how SQL Server "still seeks the assumption of absolute reliability" that Oracle and DB2 enjoy and says that the core problem is how customers implement SQL Server. I agree that companies that employ inexperienced DBAs and developers often install SQL Server by using less than optimal configurations. They go the quick and easy route, simply creating some tables and filling them with lots of data.
To be fair to SQL Server DBAs and developers, companies often place too much responsibility on IT staffers without investing in training or planning the project time frames. After all, anyone deploying SQL Server without understanding Windows NT authentication, indexes, normalization, or the timing and importance of applying service packs will run into trouble sooner or later. And when the problems occur, the blame goes unfairly to SQL Server for not securing the data or performing as well as it should.
Our company has implemented a number of databases on SQL Server 2000. One of them contains more than 10 million records and links with a remote office through merge replication. We locked down users accordingly, applied indexes, added alerts, and (hopefully) designed a robust database. We even get a pat on the back when users retrieve relevant data in a matter of seconds, and we've never lost a record.
It's All About the Community
I can't agree more with Michael Otey's Editorial "Reliability Doesn't Just Happen" (September 2003, InstantDoc ID 39661). I work on both Oracle and SQL Server, and I've seen the implementation problems that Otey talks about. To build up SQL Server's reputation for reliability, Microsoft needs to build up the SQL Server DBA community. For example, a lot of Microsoft articles assume that the developer or the systems engineer (SE) is the DBA, which is ironic because it goes against the company's enterprise initiative. Without a strong group of SQL Server database professionals, making sure the database system is implemented correctly is hard to do. Microsoft boasts that there are 80,000 SQL Server DBAs; I really doubt that number. In conducting interviews for one of our SQL Server DBA openings, we found that none of the candidates had ever done DBA work such as monitoring or restoring. Steve Ballmer says that "it is all about the community" when he battles the Linux invasion. I think that's also true when it comes to SQL Server's enterprise readiness.
Correction
In Kalen Delaney's "Sysprocesses in SP3" (September 2003, InstantDoc ID 39664), the new trace flag you use to ensure that SQL Server keeps zero-cost plans in memory is 2861; the number was transposed on the article's second page. We apologize for any inconvenience this error might have caused.
