Do you apply SQL Server Cumulative Updates?

I think Steve Jones makes a great point here with respect to cumulative updates:

“This is one reason I’ve been hesitant to remain current with Cumulative Updates (CUs). Microsoft doesn’t stand behind them, with the text on each CU page that users should only apply the patch if they are experiencing specific problems. Otherwise users are told to wait for the next Service Pack, which seem to be coming less and less often.”

When you look at the fact that service packs for SQL Server (and most Microsoft products) have been few and far between, this presents a problem. There aren’t a lot of bug fixes for SQL Server specifically, but there are important ones likes ones to fix data corruption, inaccurate result sets, and an infinite loop condition against certain dynamic management views. However, if you consider applying a cumulative update, here’s the text Steve was referring to:

“A supported cumulative update package is now available from Microsoft. However, it is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. This cumulative update package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2008 R2 service pack that contains the hotfixes in this cumulative update package. “

When was the last time a service pack released for SQL Server 2008 R2 (just taking one supported version)? It was July 26, 2012. In other words, we’re approaching the two year point. Therefore, is it wise to wait for that service pack? According to Microsoft, you should unless you are “severely affected.” However, what is meant by “severely?” If I don’t get accurate result sets back because I implement a FULL JOIN with CROSS APPLY, that’s a problem. If I have data corruption because LOB data, that’s a problem. If I try to query what’s executing and lock up my SQL Server, that’s a problem. In my view, all three of those qualify as severely. Great, but will I get the kind of support I should? If I take that text at face value, it basically says, “Installer beware.” That’s a terrible position to be in as a customer.

Which leads me to the conclusion that either (a) Microsoft should step up support on the cumulative updates and reflect this in their language or (b) Microsoft should release service packs more regularly. I don’t foresee either happening in the near future, but as a customer, I believe it’s a reasonable request.

8 Comments (+add yours?)

  1. Prashant Thakwani
    May 29, 2014 @ 02:32:55

    Good point by Steve and you and I agree that. I think they should release the service pack more frequently. But the irony is that, they concentrate on bringing the new version every two years now and leaving the old versions which are still being used by the most of their customers.


  2. Steve Hood
    May 30, 2014 @ 08:55:07

    Although it doesn’t help with the whole idea that they are too far between, Microsoft did state that they will be releasing final Service Packs for 2008 and 2008 R2.

    As for me, I typically don’t install CUs, but 2014 has some scary items being fixed where I strayed from that.


  3. Trackback: Service Packs coming for SQL Server 2008/2008 R2 | Databases - Infrastructure - Security
  4. Steven Price
    May 30, 2014 @ 11:28:46

    I am currently running SQL Server 2008R2 with SP1 and do not have any problems.
    Can I just skip SP2 and install SP3 when it becomes available?
    If I am not having any problems should I just stay at SP1?
    Any response to my questions would be appreciated.


    • K. Brian Kelley
      May 31, 2014 @ 15:54:57

      I was looking for that magical link that says you can, but I can’t find a link. However, the service packs include everything that has come before, so you can “skip” SP2 and go to SP3. This is no different than installing the base SQL Server and then immediately applying SP3.


  5. Kevin Lewis
    May 31, 2014 @ 15:28:03

    I completely agree with what has been said here. I used to only ever install service packs, but with applying 2012 SP1 then loosing several servers to software hive bloatation post install, all my new 2012 installs go to SP1 CU2.

    With releasing every 2 years maybe the expectation from Microsoft is that we have to pay for upgrades instead? Like that’s going to work.

    2008 & R2 SP3 are being released out of mainstream support. Why couldn’t MS commit to producing a service pack yearly? It’s not like there aren’t enough CU’s being released, and they’ve done it before.


  6. BateTech
    Nov 03, 2014 @ 10:44:56

    My general approach is “only install a CU when you experience the issue that is fixed by the CU, and there are no new bugs introduced by the CU after you thoroughly test in a non-prod instance”. I also like to wait a few weeks after a CU is released before thinking about installing it, so that any major issues will hopefully be reported.

    However there are 2 issues I can think of with using the “magic wait period” to identify potential issues with a given CU. 1) the issues that are reported can be hard to identify as being caused by the CU 2) sometimes the issues are not reported for months after the CU was released (see below).

    In the end, only extensively testing a CU in *my* environment with *my* applications would give me any level of comfort in installing a CU. Even then, as mentioned in your article, there can be issues that arise during the prod install vs. test, and these issues can arise with SPs as well as CUs.

    Here are a few links supporting the idea that CU’s are more risky than SPs, where a critical bug was introduced in SQL 2008 R2 CU11 that effectively “broke” RCSI, but was fixed in SP3. CU11 was released Feb 17 2014, but the Connect item for this issue was not opened until July 6 2014.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: