Editorials

Who Shares Your Database Server? – Readers Respond


Webcast:
Understanding the new culture of SharePoint
You have a sponsor for SharePoint development, you have a budget, now where are all the users? Online Collaboration powered by SharePoint is not only a new technology, but a new culture of doing work. In this session we’ll explore change management (the fluffy kind) strategies that can be tailored to your user base. Attract users, and keep your budget!

Presented by: Adam Levithan

> Register Now
> Live date: 7/28/2010 at 12:00 Pacific

Who Shares Your Database Server? – Readers Respond

Many of you have responded with a little variance. Most of the differences tend to come from the size of the company, and what components of SQL Server are utilized. Here is an example response from a company that has a lot of SQL Server investment to manage.

Patrick Says…

We have a decent number of dedicated SQL Server instances (hundreds) to support all of the different business applications utilized in our environment. Server sprawl and SQL Server “Silos” as they’ve been labeled by the Systems Admins, have become more prevalent over the last few years, and to accommodate, most of our web/application/support service servers are run in VMs. We also run our SSRS and SSAS installations on dedicated servers because the required resources to do what they’re intended to do without causing performance grief.

I’ve always been a firm believer that you must hold your ground on providing the most appropriate environment for your SQL Server databases to perform within if you have any chance of meeting rigid SLAs (written or not, expressed or implied), and rarely, if ever, allow any other applications that consume even remotely moderate amounts of memory to be run on my SQL Servers. I’ve seen too many departmental SQL Servers struggle to breath with IISExchange on them and just don’t allow it unless there’s no other way, and I document my stance early on.

SQL Server requires certain things. CPU, Memory, Storage. I rarely run into CPU issues with todays (and even yesterday’s) processors. I rarely spec a server with less than 4GB of RAM and usually much more, but there are a ton of configuration options/needs there. The I/O subsystem usually is where I have to compromise most, but that’s a whole different conversation. But right now we’re talking about role/application consolidation, and to me it comes down to how much RAM and CPU is available for SQL Server with at least 30% overheard (with a little flexibility). If there’s anything left in a departmental/dev/test server, we’ll talk about it. If it’s production, fuggeddaboutit!

Featured Article(s)
Tips for using SQL Server 2008 Distributed Queries
Here you can find some useful tips to use SQL Server 2008 distributed queries.