During our migration to our new facility and data center a few weeks ago, we lost power to the building. Again this morning, we lost building power. Let me tell you what happened.

• Our servers didn’t even blink.
• The UPS jumped in right away.
• The backup generator kicked in right away.
• Emergency lights in the data center stayed on.
• The air conditioning stayed on.
• We were able to get into the data center with our access badges.
• Every network switch on each floor of the building ran on UPS power.

This sounds like one of those “well, duh!” moments, but I have to tell you, it was revolutionary for us.  Every one of these things was problematic in our old building.

It’s wonderful when things work the way they’re supposed to.

We have a company that does some outside work for us. We have a database server at their location. We need to allow the database server to talk to our DB server in a network DMZ.  We’d use a linked server from the remote site to talk to our DMZ server. I’m okay setting up the username/password and the firewall ports. The problem is that we need to have the traffic between the two servers encrypted.

To further complicate this, we don’t want all of the traffic on these servers encrypted, just the traffic that goes across the internet.

I’m completely befuddled on how to do this properly. There is a very good chance that I’m making this harder than it needs to be, and I’d be thrilled if someone gave me a simple solution.

The following six lines of code saved me a ton of time this morning.

ALTER DATABASE [tempdb] MODIFY FILE (name = tempdev, FILENAME = ‘D:\TempDB\tempdb.mdf’)
ALTER DATABASE [tempdb] MODIFY FILE (name = templog, FILENAME = ‘D:\TempDB\templog.ldf’)
ALTER DATABASE [msdb] MODIFY FILE ( NAME = msdbdata , FILENAME = ‘G:\system\MSDBData.mdf’ )
ALTER DATABASE [msdb] MODIFY FILE ( NAME = msdblog , FILENAME = ‘e:\system\MSDBLog.ldf’ )
ALTER DATABASE [model] MODIFY FILE ( NAME = modeldev , FILENAME = ‘G:\system\model.mdf’ )
ALTER DATABASE [model] MODIFY FILE ( NAME = modellog , FILENAME = ‘e:\system\modellog.ldf’ )

I just can’t explain how big of a deal this is to me. In my current envrionment, every server was set up with a single C: drive. Some of these file systems are over a terabyte. Now we’re breaking things up, and I can only imagine the performance boost we’re going to see.

Each DB server will live on its own VMWare host. We’re virtualizing so that we can utilize VMWare’s clustering. It also gives us the flexibility to move things around. My two database servers will have identical configurations. One will server internal applications, and the other will host customer-facing applications.

Hardware wise, I’m using IBM HS22 blades with 32 GB of RAM connected to an EMC Clariion CX4-120SAN. Each server has five datastores, each corresponding a LUN on the SAN. Each virtual drive will live in its own storage group. I have a drive for:

• OS – Aps
• TempDB
• Log (LDF) Files
• Backups
• Data (MDF/NDF) files

My preference would have been to have the virtual machines use an iSCSI initiator to talk to the SAN, but I got overruled on that one. Still, this is a better configuration than I had before. (We had no SAN at all.)

Everything is 64 bit SQL 2005.  Again, I wanted to use SQL 2008, but that’s the next project.

After installing Windows and SQL, I started putting together a checklist of items to do next. Brent Ozar has a great checklist and has been a great reference. Here is my list:

1. System Center Operations Manager Agent
2. Antivirus protection
3. Quest’s LiteSpeed
4. Service Packs, Service Packs, Service Packs.
5. Set default file locations
6. Move master DB
7. Move TempDB
8. Resize TempDB
9. Move Model
10. Move MSDB
11. Load Testing

This is such a pet peeve of mine, and frankly, it’s a rookie mistake. In my environment, almost all of our applications are off-the-shelf apps with minimal customization. Today I was looking at a web-based app that is an intranet type of collaboration application. The server had Reporting Services, Integration Services, Analysis Services, and Notification Services installed. This particular application barely makes use of the database services and is database agnostic. We could run this thing on Oracle or MySQL. It’s not going to need Reporting Services, and it certainly won’t need Analysis Services.

Extra services mean extra CPU and memory utilization. While it’s not much, these little things add up. And in case of the rare bit of malware that hits SQL server, only software that’s installed can be exploited.

In a perfect world, we would have an understanding of what our servers will be doing before installing the database server. Then we would install only what’s needed. Better yet, in my environment, the vendor’s installation instructions would specify what services to install. If SSRS, SSAS, SSIS, or SSNS aren’t mentioned, there probably is no need for them.

My boss might say “We might need them some day.”  He’s right. We might need them some day. And when that day comes, we can install them. Until then, we don’t.

In addition, I’d like to win the all-expense paid trip to PASS this year. The contest closes today. I’m not syndicating this post, so it won’t qualify for the contest.

My queue has been cleared. I will continue to post here, just at a more sane pace. Thanks for all of the feedback. I’ve found that I’ve learned a lot, just by writing about what I know.