RSS Feed

Cranky Series: Database Servers are that and that alone


August 31, 2012 by Mike Hillwig

Welcome to the last post in my How Not to be a Cranky DBA series. This has been a lot of fun to write. When I first decided to turn the presentation into a blog series, I had no idea that it would take so long to write, nor did I realize that it would generate a new blog post once a day for three weeks.

When I first started my job at the networking company, I was supporting database servers and a whole bunch of applications. Each application had two servers, one for the database and appplication, and another server to be used as a backup. We had completely inefficient use of hardware.

The worst part of the situation was that we couldn’t configure the DB server to be just a DB server because it had to share memory and CPU with an application. One day I had enough, moved one of the redundant pieces of hardware to our primary data center (which was across the street from the secondary data center) and built it up as a dedicated DB server. Then I started consolidating stuff. Things suddenly started working better.

People seem to think that SQL Reporting Services, as well as Analysis Services and Integration Services are all part of SQL Server. I couldn’t disagree more. Yes, you CAN run them on the same box, but that doesn’t necessarily mean you should. The more stuff you run on a server, the more resources you take away from the database services. ┬áIt’s the same reason why I won’t allow people to use RDP to connect to my database servers.

Databases are the foundation of applications. If the database crumbles, so does everything else. For that reason, I always insist that the database server be standalone. If you need SSAS or SSIS, that’s fine. We’ll build a box for you to run those. But don’t think for a moment I’m going to let you run them on the SSDS box. SSDS: SQL Server Database Services. That’s how I’ve been referring to it in my environment to keep it straight.