When a new database version is released, a great deal of press and marketing ink is spent on discussing the latest features of that database. These usually include functionality around data, such as analytics, performance, and scalability enhancements. Functionality around less "sexy" administrative features, such as patching, rarely gets the same level of attention. With SQL Server 2008, however, the patching enhancements Microsoft has made are themselves very interesting.

SQL Server already had a reputation for being easier to patch than Oracle. Oracle maintains a complicated inventory of patches, where individual patches resolve specific bugs and potentially conflict with one another. SQL Server has a very straightforward cumulative patching strategy. General release patches for SQL Server fall into two categories - Service Packs, and Cumulative Updates. A Service Pack includes the bugfixes for all of the issues discovered up to that point, and may also include functional changes - new features, modifications to expected behaviors, etc.

Cumulative Updates are released every two months, and include all bug and security fixes up to that point, but do not modify core functionality of the SQL Server engine and other components. The idea is to give organizations the comfort level that applying a CU will resolve issues they've experienced and plug security holes, without worrying that they need to retest their applications.

The interesting twist on CUs are that they are cumulative from a given service park or RTM release. For example, there may actually be two sets of CUs available - one for SQL Server 2005 SP3 and one for SQL Server 2005 SP2. It's important to understand which CU is appropriate for your environment based on the SQL Server SP level.

Despite all of this, patching SQL Server was still a downtime event requiring the coordination of multiple components. This included staging the patch media appropriately and manually making sure that every SQL Server installation had the appropriate patches installed when the instance was deployed.

SQL Server 2008 changes many of these things. Let's start by looking at installations. For years, Microsoft Windows administrators have had the ability to create "slipstreamed" installations of Windows that have patches preloaded in the installation media. Then, whenever a new Windows install was performed using that custom media, Service Packs and hotfixes were automatically included in the installation. Unfortunately, SQL Server did not support slipstreamed media, and hence users had to manually install SQL Server RTM, then apply the appropriate Service Pack, then add any CUs or hotfixes as appropriate. This opened the door for environmental inconsistencies, as well as increasing the overall complexity of deploying a SQL Server environment.

SQL 2008, however, adds the ability to create a custom slipstreamed installer in the same fashion as Windows. Once the slipstreamed install is created, you can use the one set of media to create your SQL 2008 instances, and those instances will have all of the patches and updates installed automatically. One requirement to keep in mind - you must be using at least SQL 2008 SP1 in order to successfully create slipstreamed media. Obviously, slipstreamed media is fine for small environments, where it is easier to just create one set of media for the few installations that are going on. It can become unwieldy, however, for environments where there may be multiple standard builds - for example, if one business unit has certified 2008+SP1, while another has certified SP1+CU2. In addition, this obviously does not address the need to patch systems on an ongoing basis.

SQL 2008 has improvements in reducing patching downtime as well. With SQL 2008 in a clustered environment, it is possible to patch the passive/standby side of the cluster, fail the instance over to the now-patched node, then patch the formerly active node in the cluster. This cuts the downtime for a patching event down to just the one failover - which can be less than a minute.

There is a catch, though - the process described above, patching the passive node, failing over, patching the remaining nodes, etc. - is a purely manual one. There is no built-in orchestration for this patching process in SQL Server, so it is up to the administrator doing the patching to carefully handle this event. If the user were to incorrectly miss a step, downtime, or even possible corruption could result.

In all of these scenarios, Microsoft has increased the options available to SQL Server database teams, and added more flexibility around patching and deploying SQL Server. It doesn't change some of the core challenges people face in these areas, such as managing patch compliance, guaranteeing consistency with organizational best practices for patch events, and ensuring that a patch event does not cause unnecessary downtime or data loss. This is why GridApp Clarity™ is useful for all organizations who want to stay up to date with their SQL Server patching. While Microsoft keeps adding new ways of patching and new options, GridApp continues to update Clarity to support those methods, and help organizations take advantage of them.