While I have been working for Red Gate Software for nearly three years, it was only until this year that I have begun to get actively involved with their SQL Servers, specifically the SQL Servers used as the back-end to the www.SQLServerCentral.com (SSC) and www.Simple-Talk.com (ST) websites. Given that I live 8,000 miles away from the servers, I can’t really act as a hands-on production DBA, but in more of an advisory capacity. Red Gate has its own in-house IT staff that maintains the servers day-to-day.

As of today, the databases that support SSC exist on two different instances of SQL Server 2005, on two different physical servers. The databases that support ST exist on a single instance of SQL Server 2000, on a third physical server. These three SQL Server instances are hosted with a large web hosting company, along with separate IIS servers that host the websites.

The Red Gate Software staff is currently in the process of upgrading the old physical hardware, the OS, and SQL Server instances to the newest versions. Here’s why we are performing the upgrade:

1. The workload on the physical servers has grown greatly since there were first commissioned, meaning that two of the three physical servers are undergoing significant resource bottlenecks. Moving to larger, more modern hardware will give us the extra capacity they need to run more efficiently.
2. When the original SQL Server instances were configured on their existing hardware, they were not configured ideally. For example, MDF and LDF files were not isolated from one another, among many other problems. While some of these problems could be addressed if we were willing to bring down SSC and ST for a number of hours, others cannot be fixed without starting from scratch.  By moving to new hardware, we can make sure that the hardware, OS, and SQL Server is configured optimally, right from the start.
3. As I mentioned earlier, these servers are running old versions of SQL Server, plus older versions of the OS. As we move to the new hardware, we will also be moving to the latest versions of the OS and SQL Server, which helps us to keep in step with the new features (and performance boosts) offered by the latest versions of the software.
4. Running all the databases for two websites, on three SQL Server instances, adds to the complexity, and cost, of managing them. As a part of the upgrade, we will be consolidating the three existing SQL Server instances into two SQL Server instances.
5. The existing SQL Servers use log shipping as their only form of high availability, which has always made us feel uncomfortable, as switching from one server to another (which is currently our only option), is a manual process, and could potentially be time consuming, which means that the SSC or ST could be down for many hours. To help boost the availability of the new SQL Server instances, they will be configured in an Active/Active cluster, and the MDF and LDF files will reside on a SAN. This is still not a perfect solution, as the SAN could still fail, but we will have backups, and should be able to restore them quickly if need be. We are also looking at database mirroring or log shipping to augment the protection of the data, but have yet to make a final decision on this.

Now that you know a little about why we are upgrading our SQL Servers, in my next blog post, I will talk about the hardware that was selected, and why.