November 18, 2010 | SQL Server

Cumulative Updates for SQL Server 2008 are available

On Monday, the SQL Server Release Services team released cumulative updates for both SQL Server 2008 SP1 and SQL Server 2008 SP2.  The cumulative update for SP2 restores the fixes that were potentially undone by applying SP2 (or the SP2 CTP) after applying CU9 or CU10 to SP1.  Confusing, yes, but at least it's straightened out now.  We won't have to deal with this until the next service pack.

  • SQL Server 2008 SP1 Cumulative Update #11- build # 10.0.2804
    KB #2413738

  • SQL Server 2008 SP2 Cumulative Update #1 – build # 10.0.4266
    KB #2289254

And no, neither of these updates are applicable to SQL Server 2008 R2.

3 comments on this post

    • Jordan Bullock - November 18, 2010, 8:04 PM

      So.. SP2 CU1 has all of the fixes in SP1 CU9 and 10, but what about CU11?  
      Just seems weird to me that they're still releasing CU's on SP1, I guess.

    • Chris Wood - November 18, 2010, 10:09 PM

      Jordan,
      SP1 is still supported so they had better fix any problems with it and I would expect more running SP1 than SP2 the problems won't show in SP2 yet.
      Chris

    • AaronBertrand - November 18, 2010, 10:25 PM

      Jordan, Chris is absolutely right.  Assuming we agree that 2008 RTM is dead development-wise, this leaves two supported branches of code, SP1 and SP2.  With that in mind, I'll spew out a mix & match of facts and guesses:
      (1) a fix for one branch may not be appropriate for the other.  For example, an issue in SP1 which requires a code fix in that branch may be fixed as a side effect of a different fix in the SP2 branch, so doesn't require its own fix.
      (2) a fix for one branch may be more complicated than applying the same fix to the other.  For example, it may cause a regression due to other fixes.
      (3) a couple of months before an SP is released, development in that branch is essentially frozen (except for major issues realized through the CTP process).  So as new fixes are applied to the previous SP's branch, the current/future SP cannot benefit from those fixes (like in this case).  I don't think this is the last time you will see this.
      (4) because of (3), you'll often see new fixes for the older branch quicker than the brand new branch.  This stabilizes as the new branch matures.
      (5) because SP testing can be complex and time-consuming, it is often a slow process for a new service pack to gain wide adoption. As Chris suggested, less exposure means less people likely to pick up on bugs.  So I suspect early in a service pack's lifetime you'll see more problems found on the previous branch than the current branch.
      (6) even when problems are found in an earlier branch, they aren't necessarily rushed into the newer branch because:
         (a) they may be more complex, as described above,
         (b) they may not be as easily reproducible (potentially due to other fixes),
         (c) there may be other high-priority fixes ahead of it, or
         (d) they occasionally won't mark it for inclusion in a branch if no customer has reported it there.  (The priority is with the branch where the bug was reported.)
      (6) thankfully, they have all but given up on the should-never-have-been-a-problem practice of adding features in service packs.  If you were to factor feature development amongst the above points, you've complicated things immensely.  They still get away with minor ones (system function enhancements in 2005 SP2, true mirroring support in 2008 SP1) but in general they stay away from it – most certainly due to the additional complexity it adds.
      This is not a twitter client we're talking about, where you can just tell everyone to "get latest"; it's a very complex piece of software that needs to be maintained in several branches – and not all branches are considered equal.

Comments are closed.