Check out SQLServerBuilds.blogspot.com, a site that lists cumulative updates and service packs. Here’s a remixed version:
The first service pack seems to come out fairly quickly, but after the first one, it’s a year or more. Makes sense – you find a lot of bugs quickly, right?
Microsoft released at least one service pack per year, but … not last year. 2013 saw no service pack releases, and it’s been 442 days since the last service pack (SQL 2012 SP1) shipped.
Is Microsoft taking too long? Let’s look at each current version missing a service pack:
- SQL 2012 has been waiting 442 days for SP2 – but that’s actually right in the range for normal SP2 releases. SQL Server 2008 went 540 days before SP2.
- SQL 2008R2 has been waiting 545 days for SP3 – but that’s also less time than it took for SQL 2005 to get its SP3, so no cause for panic here yet.
- SQL 2008 has been waiting 839 days for SP4 – here we actually do see some cause for alarm, because no supported SQL Server version has gone that long without a service pack.
When you step back and take the long view, we’re not really in that bad of shape yet – but I can see why people would be disturbed that no service packs have been released in over a year. It might just be a timing coincidence, or it might be something more.
But it does beg the question – what if Microsoft just stopped releasing SQL Server service packs altogether, and the only updates from here on out were hotfixes and cumulative updates? How would that affect your patching strategy? Most shops I know don’t apply cumulative updates that often, preferring to wait for service packs. There’s an impression – correct or not – that service packs are better-tested than CUs.
47 Comments. Leave new
The night before SQL Saturday DC I was present at a discussion where Allan Hirt and at least one other MCM were asserting that yes, Service Packs might very well be over. Too much work for Microsoft, or something. They will certainly have to make the smaller updates sound more important, since most places I’ve worked even Service Packs only got applied to SQL Server after much wailing and gnashing of teeth.
I don’t think it’s just an impression that SPs are better tested than CUs. It basically states is in every CU kb article.
“This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. The updates in this 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 2012 service pack that contains the hotfixes in this package.”
Robert – that’s a fantastic point, because it even says that in the SQL Server 2008 CU posts like this one:
http://support.microsoft.com/kb/2923520
“This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. The updates in this 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 service pack that contains the hotfixes in this package.”
Since there hasn’t been a SQL Server 2008 service pack since 2011, that’s an awful long time to wait for “the next” service pack, hahaha!
I don’t think I would have said too much work, but I’m sure I speculated that their time is coming to an end or what they are will be redefined (see my comment below). I have no knowledge of what MS will ultimately do, but I can read the tea leaves (nee evidence) laid out before me. This isn’t a sudden change.
They have — they are just called SQL 20xx r2 rather than SQL 20xx sp2 these days. You can charge for the former to boot.
Wyatt – well, funny you mention it, but the release schedule has moved faster – fast enough that it’s almost the same cadence we used to get for service packs….
It’s a joke, but it’s also kind of true. If new versions are the new service packs, then as I stated above, they need to redefine CUs so that my boss will let me install them.
I’d be fine with MSFT saying no more SPs, only CUs from now on… IF they could remove the CYA wording that you should only apply them if you are experiencing a problem, because they haven’t been fully tested the way a service pack would; ideally because they would be sufficiently tested. I think they’re the ones most guilty of propagating that impression that SP are better tested than CU, whether they are or not, so if they can set the record straight I think they’d have more people willing to apply CU as part of a regular patch routine.
Personally I’d rather keep the SP’s. We’ve kept with the recommended strategy of applying SP’s only unless a CU is needed to correct an issue (rare for us). Without SP’s would we not end up with having to spend a bunch more time ($$) having to monitor and review hotfixes and CU’s to see if this one or that one applies, and oh by the way it only applies on this SQL Server but not on that other one.
It was my understanding as well that the SP’s underwent a more rigorous test protocol at MS than CU’s and hotfixes.
Haven’t they done this on the server side as well? XP had sp3, Vista SP2, 7 SP1, 8 has 8.1..
The wording of the CU scares me from applying them. IF there’s no SP2, I won’t have a choice as I think CU6 will fix a cluster resource leak for me.
That’s a great point – there haven’t been any recent service packs on Windows Server, either. Wonder if it’s a company-wide decision to stop updating existing products with service packs?
Well, we have the RUs on the Windows side now which are a whole different thing. Windows Server 2012 never got a SP – people are shocked when I point that out but it’s absolutely true.
Patching/updating has always been one of my passions in what I do, and it’s something many people do badly. That said, the whole “wait for a SP” mentality is basically going to have to go the way of the dodo. The evidence is pointing that way. Heck, the release cadences are going to force our hands whether people like it or not. It may mean that people skip two or three releases instead of one (which is a different kind of nightmare for many people, consultants included).
It will be interesting to see what MS does over the next few years with regards to patching and updating.
Just a quick not to pmpjr – if a hotfix or a CU fixes a problem you have, by all means test it, but definitely apply it. Don’t wait – problems lead to downtime.
Maybe they have moved to a more automated testing strategy. If all they are doing when testing is to push a button and have 1000 servers test away for 24h, they can release any day with full quality.
That does not replace field testing, however. I’m sure that major releases run fur quite some time in production internally and with preview customers.
Assuming service packs are no more, I would be curious how companies will determine when new releases are stable for implementation. With a large number of companies seeming to want to wait for the first service pack before implementing in production. For example at my current employer when I bring up the topic of SQL Server 2014 it is disregarded as they don’t foresee a service pack being available until 2015.
I noticed this two days ago when researching end of life dates for SQL. According to http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=sql, Service Pack support for SQL 2012 ended last week. That page also says “When support for a service pack ends, Microsoft will no longer provide new security updates, hotfixes or other updates for that service pack. ” Since SQL 2014 isn’t out yet, does this mean there will be no more updates at all (including CUs) for the latest available released version of SQL Server? Meaning we are all stuck with a product that no one will be working to patch no matter what bugs might be found?
RTM is EOL, not SP1. For purposes of this discusaion and the Lifecycle page,RTM is a SP. If you look at that link, 2012 SP1 has its own entry. This means that you should ensure any 2012 RTM is at SP1.
discussion – typo
Ah..didn’t notice that. Thanks.
I don’t think they would stop releasing CUs/Hotfixes at this point for 2012 SP1…In fact MSFT released CU8 for 2012 SP1 3 days ago…
No one is saying they’re going to stop CUs/hotfixes for a supported branch of code. It’s UNSUPPORTED branches of code such as RTM where that does not happen.
Didn’t one of the recent 2012 CUs have a fix for something broken in the previous CU? I know I’ve seen them listed before…but then again, 2012 Sp1 had a nasty bug that required a CU, so…
Yes, they did – SQL2012CU7 had an “oops!” they fixed in CU8, and SSRS had another one in CU4 that messed up cascading parameters – non-trivial I’d say.
That’s why I don’t trust CU’s until they have been out for a while and “the experts” a-la Brent, Paul, Adam, etc. haven’t raised the red flag and Connect is bereft of issue reports.
Even SP’s can’t be trusted – 2012SP1’s reboot-spiral horror for example… If SP2 came out tomorrow, I wouldn’t even look at for over a month to let the dust settle and bugs rear their heads if they exist.
As others have commented in the past, for MS to introduce significant functionality in a Service Pack that we would naturally be attracted to, only to find the SP itself is buggy, casts a shadow over MS’s policies. SP = bug fixes. New features = Add-on. Separation of concerns?
I’m on CU6 having tested it in Dev and QA for 5 months before committing to Production. As CU7 is a bust (AG and Backup/Restore issues), I’ve been VERY cautious, diligently observing the CYA verbiage and thus far, nothing significant for CU8/9 has arisen.
I think @tobi had a good point – Microsoft should, if they’re not, thrash every CU for days and days before releasing it into the wild. Perhaps if we knew that’s exactly what they did and on many and various topologies, we have greater confidence in their software. As it is today, let the buyer beware!
We’re almost at the point where SQL 2008 goes into extended support (June this year) so if MS are going to release a SP for it, they will need to do so soon. I am still holding out for a final SP release in the same fashion as SQL 2005.
I have to agree with Allen. When a CU is released, test it to make sure it does not break anything and then apply it. Why do this? My response is why should my customers come to me with a problem that was fixed by a CU 6 months ago. Especially if I already know about it.
My group manages over 200 development and production instances. Two years ago we implemented a 6 month patching cycle for all our instances. Production is patched about one month after development. This allows the various development teams to test the CU. Patching has been automated with the use of PowerShell.
I believe this is a consequence of the “fast release” that MS is being forced to do, primarily because of the cadence of updates of the competition from other operating systems: OS X, IOS and Android. Apple releases a new OS almost every year, and for some strange reason MS is thinking it has to do this too.
I’m not sure about the end-user market for “a new windows every year”, but for enterprise and server market we can be pretty sure this is NOT the right way to do it. Having to develop new products this fast means less validation and weaker support – not the kind of thing you want to your mission-critical servers.
And bugs DO happen. as an example: I upgraded my desktop to win8 really fast, and it worked fine for a few months. When 8.1 came i thougt “hey, a new name for a SP. should be safe”. Big mistake: it had a compatibility problem with my USB and kept disconnecting my external HDDs all the time. I waited a few months before realising they wont fix this and going back to 8.0.
if they are not fixing bug on the main thing they sell, I wonder if they are still as serious to Server softwares as they were some years ago…
The problem with eliminating SPs in favor of new releases, profitable as it might sound, is that we already know from hard experience how buggy RTM releases can be. I have been burned every time I didn’t wait for SP1 before putting the new version into production. So I think they HAVE to do at least an SP1 to keep sales moving.
Megan – that’s an interesting comment especially in light of the SQL 2012 SP1 challenges. In this case, SP1 was actually worse than RTM for a lot of folks.
I used to be a fan of waiting for SP1 for a different reason – I wanted other people to learn the best practices and write lots of documentation (in the form of blog posts, forum comments, StackOverflow answers, etc.) Today, just by the nature of my job, I end up getting brought in by people who *have* to be on the latest version of SQL Server because they need something in it for a business reason, so I’m not sure I see things the same way anymore. I was really curious to see what would happen in the comments here, and it’s been a lot of fun to watch.
We too, have a rule to wait until SP1 to upgrade to vnext. Because RTMs are buggy.
MS makes money selling the next version. Perhaps MS thinks it’s time for a tithe to keep SQL current rather than making us buy a new version every few years? (The versions seem to come very fast now. Maybe there will be 2 per year before long.) A tithe might be better for everybody. Rather than spending our time constantly upgrading to the next version, we can patch our current version to have new features – updates vs service packs. Our shop spends a lot of effort on SQL version upgrades. That means that we are not spending our time improving our business processes. It’s a lot of work to just stand still. Perhaps it would pay for MS to have a less painful patch/upgrade process. On the other hand, paying more for more of the same would just be more painful.
That said, the upgrade process of SQL is not so bad. If you also support TFS, then you know what I mean.
Is this, maybe, another veiled attempt at pushing people to the cloud? After all, why worry about service packs and CUs when the cloud gets upgraded automatically? I’m purely speculating, but it just seems that Microsoft really, really, really wants to get away from on-premises type of activity. My company has already said it will not be going to cloud any time in the foreseeable future so if this is Microsoft’s strategy, it will be leaving behind a lot of customers since I’m sure we are not the only anti-cloud people. It will be interesting to see what comes of this service pack situation….
Brooke
I do not want to believe in conspiracy theories but this is exactly what I been thinking. This could be a strategy to push customers to the cloud, after all software in the cloud will be patched automatically and you will not have to worry about leaving behind an important update. However it might backfire since many companies are not yet ready to take the perceived (or real) risk of having all their critical applications and data in the cloud for security or logistics reasons.
While their push to get us to the cloud is real, as is our incentive that patching is done for us in the cloud (at least for WASD), I’d say that actually means MSFT has to be just as careful, if not more so, about making sure patches don’t break anything, specifically because customers don’t have a say when that happens. Of course in the cloud they also have complete control over everything else too, which probably means they don’t have anywhere near the amount of testing to do, compared to all the configuration variations that on-premise customers have created for themselves.
This might be the most constructive blog post dialog in the history of the internet. Well done folks.
Brian – HAHAHAHA, thanks sir.
Microsoft is guilty of sending out mixed messages about the CUs. This point was already raised here, but additionally, Microsoft System Center Advisor raises warnings like this one on an instance with 2012 SP1 (build 3128):
The SQL Server build on this instance is lower than SQL Server 2012 CU4
So are we supposed to install the CUs or wait for a Service Pack?
Well, I think the last sentence is the key. “There’s an impression – correct or not – that service packs are better-tested than CUs.” Is it correct or not? I don’t know. I think maybe that if they are to reduce or kill service packs then they maybe need to be more upfront on their testing methodologies and what level of that testing was applied.
I’m guessing that the time increase is directly related to the size and complexity of the SQL SERVER product. I would think that the amount of time it takes to run automated regression tests is in the order of days or longer. We found a bug in SQL SERVER to do with partitioning indexes – it was fixed in 2012 sp1 CU7 – but MS asked us for business justification to fix it. Hello – we pay for multiple enterprise licenses 🙂
Martin – hmm, why would SQL Server 2008 need 839 days to get SP4 then? Are you saying that SQL Server 2008 got significantly more complex after SP3 was released?
Well, over 2.5 years is far too long (nearly 27 if you happen to be a cat 🙂 ) – but seriously, I love to know the the tipping point at which a bug fix (or similar) is elevated from a CU to an SP – maybe the time frame is related to “less serious” bugs being found or bugs that affect fewer people. Just a thought 🙂
Based on this definition of “Service Pack” from Microsoft:
“A tested, cumulative set of all hotfixes, security updates, critical updates, and updates. Additionally, service packs may contain additional fixes for problems that are found internally since the release of the product. Service packs my also contain a limited number of customer-requested design changes or features.”
I would be interested to know how they would roll out “additional fixes for problems that are found internally since the release of the product” as this definition seems to imply that they would not be available in a hotfix/cumulative update.
If they realy plan to stop developing SPs, as I read here, it would be nice, if they start to rollout CUs over Windows Update, as the do with SPs. Because it is really annoying to request every single CU through register by email addrress, wait for the answer and than download the binary.
So looks like they are still releasing service packs: http://blogs.msdn.com/b/sqlreleaseservices/archive/2014/02/13/update-on-the-service-pack-plans-for-sql-server.aspx not exactly clear on when we can expect SP2 for SQL Server 2012 though.
And SP3 for SQL Server 2008 R2 is out now:
http://www.microsoft.com/en-us/download/details.aspx?id=44271
This is similar to how there never was a SP3 for Windows 2003. Even though they should have.
http://blogs.technet.com/b/windowsserver/archive/2009/09/15/support-changes-coming-july-2010-for-windows-2000-server-and-windows-server-2003.aspx
At the time, I insisted to have all over our Windows 2003 servers to have SP2, and all the “Recommended hotfixes for Windows Server 2003 Service Pack 2-based server clusters”
https://support.microsoft.com/en-us/kb/935640
The reason, is before we applied those additional recommended hotfixes, we had several outages due to those various bugs.
I agree, that for some reason, some people won’t install recommended patches, only recommended Service Packs.
I’ve also noticed, that microsoft sometimes will “slip in” various bugfixes packaged in with security patches, because they know that people are more willing to install security patches, than bugfix patches.
Service Pack 3 for SQL Server 2012 was released on November 21, 2015, so the service pack process in Microsoft has not stopped yet.