Introduction

This is the second part of the Tips for Upgrading a Cluster to SQL 2008 series. On the first part I covered the basic steps for facing the SQL Server upgrade. On this article I’ll cover the actual process of the SQL Server upgrade.

Upgrading the SQL Server

Now that the steps needed to perform the upgrade were identified and documented, it’s time to put things in motion and upgrade SQL to the 2008 version. For the process outlined, I’ll assume the steps identified on the part 1 (http://www.sqlservercentral.com/articles/cluster/74804/) are already done and in place.

Just as a quick information refresh, this upgrade is done in a four node cluster with an Active/Active/Active/Passive configuration. Also, the following names will be used in this article as reference:

Nodes

• ServerA
• ServerB
• ServerC
• ServerD

SQL Instances

• Instance1
• Instance2
• Instance3

The first step to perform the upgrade is copying the installation binaries to a local drive in each node or to a share folder in a server reachable from all nodes. Next, to reduce the downtime of the instances, fail over all resources to one node. That will leave three instances running in one node and nothing running on the other three nodes. To achieve this, simply go to the Cluster Manager and fail over all resources to ServerA. After that is done, go to ServerB and start the upgrade process but launching the SQL 2008 Setup. During the upgrade process on ServerB, the installer will detect the installed instances and will prompt to choose which one to upgrade. The first instance is selected (Instance1) and then complete the rest of the wizard’s steps until you reach the Ready to Upgrade step. After reviewing carefully the information on that screen, we proceeded with the upgrade.

Once the upgrade process has finished, it’s time to repeat the process on ServerB but for the next instance, which in this case is Instance2. Again, launch the setup wizard and select the Instance2 as the instance to upgrade. Review carefully one more time the information on the Ready to Upgrade screen and perform the upgrade. This time, because some features were already upgraded (like the client tools and other shared features), the overall upgrade process will be shorter than the one taken for Instance1.

After the Instance2 upgrade is complete, it’s time to perform the upgrade on the last instance on ServerB. For the last time on this node, launch the SQL setup again, select Instance3 as the one to upgrade, review the information on Ready to Upgrade and perform the upgrade.

Once the third instance is upgraded on ServerB, the same process must be applied on the next server that is not hosting the active SQL Instances: ServerC. After connecting to this server and starting the SQL upgrade setup process, we perform the same actions as on ServerB, upgrading one instance at the time. Finally, and after the three instances were upgraded on ServerC, we connect to ServerD and repeat the process.

At this point we have the three instances upgraded on the three passive nodes, so next we need to perform the upgrade process on the node that has the instances running: ServerA. The steps are no different than the one outlined for the other nodes, stopping on the Ready to Upgrade screen of the wizard to validate the information and performing the upgrade one instance at a time. In this case, the only difference is that after performing the upgrade, the setup process automatically fails over the resources to another node. So when you finish the upgrade of the Instance1 on ServerA, if you go to the Cluster Manager you’ll see that now Instance1 is no longer running on ServerA. Same will happen with the other instances.

After all instances were upgraded on all servers, the complete SQL Cluster is upgraded to SQL 2008. As a general rule, the upgrade process in a company starts with the upgrade of test or sandbox machines, next development and staging environments and finally production. This includes not only the upgrade of the version (SQL 2005 to SQL 2008) but also the update of the instances through the service packs. That was the case on my environment, so if that’s the case on yours too it’s time to install the service pack for SQL 2008. Again, all instances should be running in one node and the service pack installation should be done first on the passive nodes, so we’ll have Instance1, 2 and 3 running on ServerA and we’ll start the service pack installation on ServerB.

The setup process will ask which instance to upgrade, so we’ll choose Instance1 and perform the update. Once finished, we’ll run again the service pack installation and choose Instance2. Again the update process will be shorter compared to the update of Instance1 as some shared features were updated already. Finally, repeat the same for Instance3. After updating all the instances, repeat the process on ServerC and ServerD.

At this point, all passive nodes has the service pack installed and it’s time to perform the update on the active node (serverA), so connect to it and perform the installation of the service pack. The process won’t be different at all as the one on the other nodes as we’ll update one instance at the time. Once the three instances were updated, the SQL Instances 1, 2 and 3 are at the same patch level on all nodes.

Conclusion

Performing the upgrade of SQL Cluster instances can take several hours, depending on the configuration of the cluster and the quantity of instances running. If your maintenance window is big enough to perform an in place upgrade, then you can attempt it. Finally, remember to write down your plan and review it over and over before starting.

On the next article I’ll discuss the post-upgrade steps needed to complete the SQL upgrade to 2008.