Over the last month, I’ve been tasked with coming up with and implementing three new SQL Server installations. These are brand new servers that will have brand new drives and we’re starting from the ground up. For those of you who are production DBAs, this might be that terrifying, but keep in mind that 1) I’m primarily a database developer (development DBA, whatever) and 2) I’m a consultant. I’m being tasked with a decision that will last long after I’m gone from my client. While this may be old hat to some people, this is well outside of my comfort zone. Typically I say something like “write the biggest check you can.” Unfortunately, that’s not an acceptable recommendation.

What’s a lone data monkey to do?

I took to Google. Luckily Kendal Van Dyke had written a great set of articles about physical storage configuration. After reading through his series, I was able to determine our disk formatting requirements and justify them to the Windows administrators. I remembered that Rod Colledge had written a post about storage/SAN configuration that I had initially dismissed because “I’m a development DBA and I’ll never have to configure a SAN!” Thankfully I was able to track down Rod’s excellent article on storage configuration and, after a few questions on twitter, Brent Ozar took the time out of his day to answer some of my questions about SANs (turns out they aren’t magic boxes). Brent was kind enough to continue a back and forth conversation via email about my proposed SQL Server configuration. After outlining everything in detail, I was absolutely overjoyed to see the first sentence of his reply contain these words “you made a lot of good decisions there”.

Where the hell am I taking this feel good story?

Remember how I said I work in physical isolation? Well, I still do work in physical isolation. Having access to my RSS feeds, twitter, email, and forums makes that physical isolation a lot less apparent. I’m able to access the collective wisdom of a lot of experienced DBAs, take their combined wisdom, and synthesize a solution that meets the needs of my current situation. Would it have been a lot easier to sit down with someone over coffee and outline the situation and wait for recommendations? Yes. Would I have learned as much? No.

Why haven’t I actually said anything about the configuration we’ve ended up with? One, it’s not actually in place yet. Two, I need to write it up and get explicit approval from management before I release any information to the public. They are quite secretive about their configuration and schema and I can completely respect that. Hopefully, though, I will put the scenario together and will be able to share it with the world.

Here’s the fun part – I’ve never done this before, at least not on a production machine.

What best practices, secret tricks, or hare-brained schemes do you, my fellow DBAs, follow when you put together a new SQL Server installation?

This could be anything from drive configuration, something about SANs, trace flags, whatever. You name it, I’ll evaluate it and confer with other smartypants types and once the install is done, I’ll let you know how everything goes.

Oh, the hardware is going to be a dual CPU quad Xeon machine from Dell with 16GB of RAM. And we do have a SAN of some nature, but that’s a mystery box.

Edit: So, what will these machines actually do? They will serve reports off of an OLTP schema that is updated every 15 minutes through replication from our master database server. There will be two instances on each machine – one that is live and one that just sits there, doing nothing. They mirror each other, in addition to the geographic fail over that somebody else is configuring. We do some heavy batch processing in the early morning hours, but during the day the machine is largely doing reads and whatever writes that the replication brings about.

The database that holds the majority of the reporting data is about 45GB and there is approximately 25GB of metadata and summarized reports (the batch processing, naturally) in a second database.