Dan Guzman Blog

Not Before Service Pack 1

In case you haven't yet heard, Microsoft SQL Server 2008 service pack 1 was released on April 7.  This milestone is especially significant for those of you who could not previously deploy the latest SQL Server release because your organization has a "not before the first service pack" policy.  I want to go on record as one who believes that such a policy is flawed and has needlessly delayed many organizations from using the new SQL Server 2008 features.

There is nothing magical about the first service pack compared to the initial RTM release with regards to production readiness.  SQL Server releases nowadays are scheduled based quality rather than just hitting a date.  Buggy features will be dropped from a release rather than included and in need of a service pack.  I'm not saying that every SQL Server release is flawless but the number of serious bugs (e.g. corruption or wrong results) are few, thanks to internal testing by Microsoft as well as those in the community that kick the tires with the pre-release CTP bits.

It's understandable that those who are risk-adverse might wait until after the first service pack with the belief that other adopters may have smoothed out the bumps in the road a bit.  I can see how postponing installation in this way might mitigate some of the risk but SP1 is a completely arbitrary milestone that is a hold-over from before SQL 7 was released over a decade ago.  I think a better approach is to adopt new releases based on quality as determined in one's own environment.  Whether the target is a new SQL Server installation or an upgrade of an existing instance, one still needs to perform testing before installing any new version, service pack or patch in production.  It is those test results that should determine production readiness, not the results of SELECT SERVERPROPERTY('ProductLevel').

Legacy Comments


Peso
2009-04-19
re: Not Before Service Pack 1
That's true nowadays in most cases, however the new MERGE command desperately needed a hotfix before SP1.
So not all features are 100% tested before released.

Peso
2009-04-19
re: Not Before Service Pack 1
I forgot references:
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=357419
http://www.sqlmag.com/Article/ArticleID/100155/sql_server_100155.html

Dan Guzman
2009-04-19
re: Not Before Service Pack 1
Peso, you are right that all features are not (and cannot be) 100% tested before release. The hotfix for this MERGE bug was released at the same time as the RTM version so that it was immediately available to those affected.

This sort of bug would likely be caught before production implementation with even cursory testing. As an alterantive to waiting for SP1, affected customers could have either used one of the workarounds (http://support.microsoft.com/?id=956718), installed the hotfix or installed the first CU.


Mike H
2009-04-22
re: Not Before Service Pack 1
Even waiting for SP1 sounds terribly risky to me. We just migrated to SQL 2005. Staying one full release behind is much safer, plus I can buy your used manuals on e-bay for $5 <grin>

Microsoft makes money on new features, but I rarely NEED a new feature, and never value them as much as I do reliability and stability. Nor do I need the expense and headaches of learning a new feature set just to re-implement solutions that already worked fine. (Speaking as a former DTS designer who got to redo it all with SSIS)

Dan Guzman
2009-04-22
re: Not Before Service Pack 1
I remember eating crow after a customer went ahead and upgraded to SQL 7 against my advice to wait for SP1. It turned out that SQL 7 RTM release was more solid that the version 6.5 ever was.

I also value reliability and stability over new features. But my view is that you can have your cake and eat it too. The best way to ensure quality is to test your own application, something you'll need to do regardless of when you decide to take the plunge. You'll at least have the option to use new features if you upgrade.


Dave DuPlantis
2009-04-23
re: Not Before Service Pack 1
From my perspective, one of the problems with being an early adopter is that I can't test my applications completely any more than Microsoft can test the next SQL version completely ... and if the apps are running fine now, the onus is on me to correct any issues we have as a result of the upgrade.
It isn’t simply a matter of SQL itself, either, but also the other tools that we use in conjunction with the database. Maybe there’s a problem with SQL 2008 and ColdFusion 8 that didn’t exist with SQL 2005, and if that’s the case, it’s much easier to get those resolved by turning to the community as a whole with questions … it benefits me more as a web developer/DBA to wait to upgrade until enough other people have my configuration that I can get answers better than “well, I didn’t have that problem in 2005 either.”

Dan Guzman
2009-04-28
re: Not Before Service Pack 1
Hi, Dave.

I understand your point that it's easier to adopt later than sooner. But how do you know when "enough other people have my configuration"? The main point of my post is that the SP1 milestone is arbitrary and the real measure of readiness is that it is stable with your application/tool mix.

IMHO, the single best indicator that a SQL Server release is ready for your environment is passed your regression testing. I seldom see major issues for those that perform due diligence before the upgrade rather than rely on others to do it for them.

Freestyle Medela
2010-06-11
re: Not Before Service Pack 1
Before service pack 1 things were going okay, after service pack 1 things got better!!!!!
Chris