THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | Join | Help
in Search

Aaron Bertrand

Aaron is a senior consultant for SQL Sentry, Inc., makers of performance monitoring and event management software for SQL Server, Analysis Services, and Windows. He has been blogging here at sqlblog.com since 2006, focusing on manageability, performance, and new features; has been a Microsoft MVP since 1997; tweets as @AaronBertrand; and speaks frequently at user group meetings and SQL Saturday events.

Mis-steps in the publication of Cumulative Updates

It used to be very difficult to obtain hotfixes for SQL Server (sometimes even to learn about their existence), and they were often unsupported.  They have made extremely great strides in this area, and in general, I find the new procedure much more convenient : just go to the KB article, select the fix(es) you want, and you get an almost immediate e-mail with download links and brief instructions.  No longer do I have to raise an issue with customer support and prove to them that I am both affected by the issue and responsible enough to handle the patch correctly.  But there are still some holes in the process.

1. Trying to be "smart" about platform

The hotfix download page determines your platform and language and offers you the patch files for your current local environment.  While this might be a good idea in some cases (such as client patches), for SQL Server this makes no sense at all.  This methodology assumes that I am downloading patches only for my immediate machine, when in reality I am usually downloading for a variety of instances, many of which are not even on the same subnet as my workstation.  Add to this the fact that in my experience the code just doesn't work - this is a pure x64 machine, and yet because I am using Firefox, the download page for every cumulative update thus far has limited my view to the x86 files.  It is only a minor piece of extra work to get access to the x64 files I'm really after (simply click on the "Show hotfixes for all platforms and languages" link), but ideally I'd like to see a setting where (via a cookie, or LiveID, or something) I could say "always show all platforms" or "always show both x64 and x86 files."  Or take away the "smarts" that hide the other platforms from me in the first place - presumably this is just a way to avoid actually documenting the files in sections, so silly people don't download files for the wrong platform.

2. Publication of correct files and filenames

While the screen shot will only highlight the repeating spelling error ("cumlative" vs. "cumulative") that has afflicted the last few cumulative updates, there was a pretty serious mistake in this most recent CU where the SP1 download actually contained the patch for RTM.  Now a lot of people are extracting the file, trying to run it against their SP1 instances, and it finds there is nothing to update.  Rather than assume a simple case of mistaken identity, many will assume that either the patch or their environment is broken.  Right now you'll notice in the screenshot below that the core file has been pulled from the download page, so they are fixing the problem - in fact it has probably been corrected by the time you are reading this.  But why was it wrong in the first place?  Are the download packages not tested even once before they are published?

3. Being vague about the included files

There are always several files in each CU download, and they are not explained anywhere either on the download page or the original KB page.  What is a "SapBi" or "RB2ClickOn" file?  Do I need it?  Who knows? I really believe that for each CU they need to have some section on the download page describing the use case where you would want to download any of the smaller files individually.

The proof

The proof is, as they say, in the pudding.  You can see the highlighted areas in the screenshot from the points above (click to embiggen):


What to do?

Without direct interaction with those involved, I am not sure what else we can do to make corrections to these processes.  The feeling of a CU is already inherently "rushed"; then when the files are published clearly without testing or attention to detail, that rushed feeling is exaggerated.  I have commented about this problem on Connect and in a previous bog post.  I've also stressed the need to fully document CUs before releasing them (but somehow left out the "testing" part).  After today's incident, it is obvious there are still some items that have room for improvement.

At least from the outside, they look like relatively simple things to fix.  Fixing them would lead to a lot less confusion among the customer base, and a lot more confidence in the general approach and attitude toward releasing updates.  A lot of that is just about better communication.  For example, while they were fixing this problem, they did not make any announcements whatsoever; they simply pulled the core files from the download page.

Published Wednesday, January 20, 2010 1:31 PM by AaronBertrand

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Twitter Trackbacks for Aaron Bertrand : Mis-steps in the publication of Cumulative Updates [sqlblog.com] on Topsy.com said:

January 20, 2010 1:40 PM
 

AaronBertrand said:

Quick update: Bob Ward told us about a quick blog post on the snafu with the SP1 vs. RTM CU files:

http://blogs.msdn.com/sqlreleaseservices/archive/2010/01/20/sql-server-2008-rtm-cu9-packages-were-uploaded-in-place-of-sql-server-2008-rtm-cu6.aspx

January 20, 2010 1:59 PM
 

Dan Shargel said:

Thanks for the post.  I can't say how much this inspires confidence in MS that they push out RTM CU9 as SP1 CU6.

January 20, 2010 4:00 PM
 

AaronBertrand said:

Yep, and still waiting for the corrected files to be posted.  Hopefully the delay is because they are testing the downloads.

January 20, 2010 4:08 PM
 

Glenn Berry said:

Is embiggen a Canadian word?  I absolutely agree that someone should have at least tested the download packages before they were posted, and that Microsoft should document what the smaller packages are in more detail.

January 20, 2010 5:19 PM
 

IL said:

January 21, 2010 1:57 AM
 

AaronBertrand said:

Glenn, no embiggen is not a Canadian word, I picked it up years ago from fark.com.

IL, thanks for the update.

January 21, 2010 9:50 AM
 

Richard said:

I always thought that the Simpsons invented the word "Embiggen":

"A noble spirit embiggens the smallest man."

"I don’t know why; it’s a perfectly cromulent word."

"He's embiggened that role with his cromulent performance."

http://en.wikipedia.org/wiki/Embiggen

January 25, 2010 9:07 AM
 

Brian said:

Did you ever figure out what the different downloads being offered were for?  For example, the "SapBi" or "RB2ClickOn" or "RSSharepoin" items?

I suspect SapBi = some component that integrates SAP into SQL Server.

I suspect "RB2ClickOn" = Report Builder 2 Click Once

I suspect "RSSharepoin" = something related to either the SharePoint reporting services Add In  or the RSSharepoint dbs.

I am trying to figure out if these are needed in addition to core DBMS update (which I suspect is just the Cumulative Update file with no other text appended to it).

August 31, 2010 1:14 PM
 

Aaron Bertrand said:

Nothing definitive that I have found, no.  I think your guesses are as good as mine, and unless you are obviously running the types of services they allude to, only the primary CU file is necessary.  (It should find those other components and update them as well, I would expect... those seem to be for specific, stand-alone things.)  If you have to ask what it is, you probably don't need it.  :-)

August 31, 2010 1:19 PM

Leave a Comment

(required) 
(optional)
(required) 
Submit

About AaronBertrand

...about me...

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement