If you were to develop a list of the top ten issues
that a group of DBAs will argue about, one that's sure to appear is the
approach to installing service packs.
1. Installation considerations
You must consider a number of important factors before making the decision to install a service pack:
Third-party application vendor support—Most
application vendors include supported SQL Server versions and service
pack levels in their support agreements. In such cases, a service pack
upgrade is typically delayed until (at least) it becomes a supported
platform.
Test environments—The
ability to measure the performance and functional impacts of a service
pack in a test environment is crucial, and doing so counters a common
argument against their installation—the fear that they'll break more
things than they fix.
Support timeframes—Microsoft publishes their support lifecycle at http://support.microsoft.com/lifecycle.
While an application may continue to work perfectly well on SQL Server
6.5, it's no longer officially supported, and this risk needs to be
considered in the same manner as the risk of an upgrade. It's not
uncommon to hear of situations in which an emergency upgrade is
performed as a result of a bug in a platform that's no longer supported.
Clearly, a better option is to perform an upgrade in a calm and
prepared manner.
Complicating the decision to apply a service pack is the inevitable discussion of the need for application outage.
2. Application outage
A common planning
mistake is to fail to consider the need for scheduled maintenance;
therefore, a request to apply a service pack is often met with a
negative response in terms of the impact on users.
Very few organizations
are prepared to invest in the infrastructure required for a zero outage
environment, which is fine as long as they realize the importance of
planning for scheduled outages on a monthly or quarterly basis. Such
planning allows for the installation of service packs and other
maintenance actions while enabling the management of downtime and user
expectations.
|
Microsoft has recently moved to an incremental servicing model (http://support.microsoft.com/default.aspx/kb/935897/en-us)
whereby cumulative updates, consisting of all hotfixes since the last
service pack, are released every 2 months. In addition to the bi-monthly
release, critical on-demand hotfixes will be delivered as soon as
possible, as agreed between Microsoft and the customer experiencing the
critical issue.
|
So with these issues in mind, let's take a look at a recommended approach for installing SQL Server service packs.
3. Recommended approach
Although each environment
will have its own special circumstances, the following approach is
generally accepted by most DBAs (see figure 1 for a summary):
For a new deployment of SQL Server, use the latest service pack available, subject to application vendor support policies.
For
existing production systems, aim to apply service packs as soon as
possible after their release—for example, at the next
available/advertised maintenance window. This will require preparation
and budget to ensure the availability of test environments for
regression testing.
Only
apply hotfixes or cumulative updates if there's a particular need—that
is, you're suffering from a bug or security vulnerability that's fixed
in the release. If you're not in this category, wait for the next
general service pack.
If
you're denied the chance to apply a service pack, for example, an
objection to the required downtime or fear of the unknown consequences,
ensure management is kept informed of the Microsoft support lifecycle
for previous versions of SQL Server.
