email article printer friendly

Managing SQL Server Proliferation
Control costs and improve support with a centralized SQL Server management strategy.
by Mark Shainman

Posted October 23, 2003

About This Article: This article is adapted from META Delta SIS 1004 "Managing SQL Server Proliferation." Copyright July 2002, by META Group. Reproduced by permission. All rights reserved.

The growing popularity of Microsoft SQL Server has caused the proliferation of instances of the database throughout the enterprise. However, this widespread adoption with little IT oversight has also produced management issues. To control costs and improve support, your organization should consider employing a centralized SQL Server management strategy coupled with standardization and consolidation.

SQL Server's penetration within organizations has been due in large part to its ease of deployment, management, and price performance. This has resulted in a highly distributed infrastructure, with increased maintenance effort, less integration, and limitations on skill, tool, and process reuse. Through 2006, several factors (such as larger, more robust Intel servers, infrastructure price/performance concerns, and the improved reliability/scalability of the Windows operating system) will cause many organizations to adopt SQL Server as a viable enterprise database option. If this is true in your organization, your IT group needs to become serious about enhancing infrastructure flexibility/manageability by consolidating SQL Server instances and servers.

Organizations have traditionally implemented SQL Server in a decentralized manner, enabling IT organizations (ITOs) to develop and deploy applications rapidly on a workgroup, departmental, or business-unit level. Often, SQL Server instances operated with little or no database administrator (DBA) support, and development groups viewed them as a quick-and-dirty method of rolling out useful but noncritical solutions. The lack of any standards or centralized DBA support has caused ITOs pain as noncritical applications have grown in popularity and importance. With SQL Server applications becoming business critical, ITOs must provide higher levels of database availability as well as data quality within a highly distributed quagmire of SQL Server instances. By 2004/05, most Global 2000 organizations will move toward a more centralized DBMS environment.

Centralize Your SQL Server Architecture
With technical changes within the SQL Server product, and the maturing of the Windows OS, you should consider several consolidation options. You could collocate numerous small Intel servers that host SQL Server into a single data center, which would also enable you to centralize SQL Server management staff. You might also consolidate duplicate SQL Server database instances for the same application, or consolidate numerous small applications with similar workloads onto separate databases within a single SQL Server instance. Finally, you can consolidate a small number of noncritical SQL Server instances onto a single server (this is possible with SQL Server 2000).

The centralized SQL Server architecture should be a standard for applications that are relatively critical and need tighter control over data (such as nondepartmental applications). This fosters a more adaptive infrastructure, enabling tighter control over operational and decision support systems while lowering software, hardware, and manageability costs.