The OS Isn't the RDBMS


In response to Brian Moran's SQL Server Magazine UPDATE Commentary "Beyond SQL Server" (October 9, 2003, InstantDoc ID 40489), I'd like to add that good DBAs know the OS they're running on. The major problem is the reverse, with many OS administrators lacking good DBA skills. With the distinction between DBA and OS administrator becoming blurred in the Windows world, the proliferation of poorly built, poorly configured, and poorly maintained SQL Server instances will increase. I've built solid relational database management system (RDBMS) instances, maintaining more than 200GB of data and 24 x 7 uptime. And I shake my head at many SQL Server installations that OS administrators have installed. They have their Microsoft certification, complete with the SQL Server component, but a piece of paper is no substitute for quality DBA skills. Microsoft's plans to increasingly reduce the tuning control that DBAs have over SQL Server are worrisome. We should at least have an advanced option that would let us tweak the system for better performance and effectiveness. Although I understand some organizations wanting a shrink-wrap solution that they can deploy and forget, larger systems need more granular control by the DBA, who knows the differences between RDBMS needs and OS needs in regard to memory usage and allocation, disk usage, CPU usage, threads, and other resources. So, I just ask the Microsoft design engineers to not get too caught up in encapsulating logic so that the OS can do everything. There's room for other logic and deployment methods, and there's value in having specialized knowledge and not having to be a jack-of-all-trades (but master of none).

Take Time to Add Features


I hope the Yukon delay that Michael Otey talks about in his October 2003 editorial, "The Great Delay" (InstantDoc ID 40014), has as much as or more to do with Microsoft's attempt to catch up feature-wise in the database space as it does with avoiding "releasing a product that isn't ready for prime time." In working with Oracle as well as SQL Server, I've found the following areas that SQL Server needs to address: end-to-end diagnostic and reporting functions built in to the system, active clusters and various flavors of partitioning, something akin to Oracle's neat resumable space allocation feature, static execution plans, ease of adding cluster nodes, portability (obviously, this will never happen), and general ease-of-use and automation features. The marketplace has far too much competition for Microsoft—and its customers—to be satisfied with simply something that "works." I hope that Yukon's new features will be market-driven rather than driven mostly by internal and external pressures from bad code, hackers, and so on.

CORRECTION


November's Exploring XML column, "Using XML Bulk Load with Identity Columns" (InstantDoc ID 40239), contained an incorrect URL on page 33 for downloading SQLXML 3.0 Service Pack 2 (SP2) Beta 1. The correct URL is http://www.microsoft.com/downloads/details.aspx?FamilyId=4c8033A9-CF10-4E22-8004-477098A407AC&displaylang=en. We apologize for any inconvenience this error might have caused.