Starting with yesterday’s release of SQL Server 2017, Microsoft has a new servicing model: they’re only delivering Cumulative Updates, and not doing Service Packs.
- SPs will no longer be made available. Only CUs, and GDRs when needed.
- CUs will be delivered more often at first and then less frequently. Every month for the first 12 months, and every quarter for the remainder 4 years of the full 5-year mainstream lifecycle.
- CUs are delivered on the same week of the month: week of 3rd Tuesday.
I adore this change for a few reasons:
- It makes patching simpler – no more trying to figure out which CU branch you’re supposed to be on
- It makes scheduling easier – if you take, say, quarterly outages, then you can just apply the most recent CU available based on your downtime schedule
- It removes the “wait until SP1” stigma – there’s a good chunk of the population that thinks a product isn’t ready until the first major update, and now maybe they’ll see the first monthly CU1 as that adoption point.
This will influence how people see versions.
Examine this sentence closely:
“Every month for the first 12 months, and every quarter for the remainder 4 years…”
That means in November 2017 – October 2018, SQL Server 2017 is going to get monthly patches. However, starting in November 2018, it’s going to be more stable.
So now fast forward to late 2018, early 2019. You’re about to build a new SQL Server for a project, and you have two choices:
- SQL Server 2018 – which is basically the new dev branch, getting monthly updates, or
- SQL Server 2017 (or 2016, or 2014) – which is the stable branch, getting quarterly updates
Once a version has hit CU12, and it only gets updates once a quarter, it might be considered Good Enough For Our Apps. Managers might see 2017/2016/2014 interchangeably at that point – which might be great for the second most recent version’s adoption.
CU 12 might be the new SP1.
I can see managers saying, “Well, I don’t wanna go to a new version of SQL Server until they’ve eased up on the fast-and-furious update stream. I can’t take an outage every month to apply patches. Plus, based on the looks of some of these bugs they’re fixing, the software’s not really ready for prime time yet.”
And I wouldn’t blame them. After all, check out just some of the highlights from the most recent Cumulative Update, 2016 SP1 CU5:
- Stack dumps when you query a DMV
- Also, when you query this DMV
- Stack dumps when you query a clustered columnstore index where “the data pages are too far apart” (whatever the hell that means)
- Wrong query results with memory-optimized table variables
- Availability Groups automatic seeding randomly fails
- Errors when you resume a suspended Availability Group database
- Crashes due to spinlock contention
- Managed backups…don’t
And remember, this isn’t the fifth Cumulative Update for 2016: it’s the fifth update FOR 2016 SERVICE PACK 1. If you deployed SQL Server 2016 in June 2016 when it came out, you’d have had 8 patching outages by now to fix stuff like this.
Which is fine: adoption is slow anyway.
In the company chat room, Tara pointed out that few people jump on the most recent release anyway. SpotlightEssentials reports that <10% of servers are using SQL Server 2016 even today. That means ~90% of servers would be on the stable branch, getting CUs only once per quarter.
Years from now, I think we’ll all be glad that Microsoft took this step and switched to a simpler servicing model. There’s going to be a few pains as we explain to managers that no, you don’t need to wait for SP1 anymore – but depending on your stability goals and patch windows, you might wanna wait for CU12. (However, 90% of you aren’t installing the new version in the first 12 months anyway – so you’re unaffected.)
12 Comments. Leave new
The 12 updates in the first year is good if you have a long project to migrate to the next version as you can get things fixed quicker. If Microsoft move to more releases ie SQL 2018/ 2019/ 2020 then the old SP1 is in fact a brand new version.
You should also remember that a fix in a new version can mean a fix in an older version too some times.
Chris
Based on this, do you think they will release any more Service Packs for SQL 2012 or 2014 or just continue to release CU’s?
That’s a great question. Given their maturity levels (they’re already past the one-year mark), I wouldn’t be surprised if Microsoft slowly consolidated down to one SP branch, and then only did CUs to that SP from here on out.
It’s an interesting change because historically, they’ve “sealed” a version closed by giving it one last good service pack and calling it quits.
Mike,
Microsoft promised SQL 2012 SP4 https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-sql-server-2012-service-pack-4/
It didn’t make either of the original or the deferred dates but is now earmarked for really soon.
That probably indicates that SQL 2014 could very well have an end of support service pack too.
Chris
And it has just come out. Build 11.4.7001
I have zero confidence that testing for CUs are the same as SPs. CU8 for SQL2012 SP3 caused us several outages. Now we are waiting for SP4 to be released so we can remove the workaround. I don’t recall ever having issues like that with SPs.
Anecdotally it were service packs in the last years that brought ugly bugs and not the cumulative updates.
Check it out for SQL 2014 SP1: https://www.brentozar.com/archive/2015/04/breaking-news-dont-install-sql-server-2014-sp1/
SQL 2016 SP1: https://www.brentozar.com/archive/2016/11/sql-server-2016-sp1-bug-graphical-execution-plans/
https://blogs.msdn.microsoft.com/sqlreleaseservices/sql-server-2016-sp1-known-issues/
Bill,
I wouldn’t put all the blame on the SQL team. W have a weird backup issue that comes and goes after we apply Windows 2016 patches.
Chris
Thats bad news for me, because at the moment we only apply SPs and this takes already very long for 350+ Instances. I already had a big issue with a CU for SQL which lead to a memory leak.
And what abt. the Lifecycle without SPs – they always extended it in the past.
The Release Cycle for new Versions is already a pain in the xxx. We could easily fill the time of one or two DBAs with upgrading…
Gerald, this change does not prevent you from maintaining a similar patch rate to that provided by SPs.
From the article:
Q6: Previously, once SP2 was released (for example), if I was on the RTM baseline I would have to upgrade to SP1 or SP2 to get a hotfix. How will this work now?
A6: The only baseline will be RTM, and it will receive CUs for 5 years. There are no upgrades to an SP to receive CUs, or worry about which baseline a CU applies to.
Don’t forget that most new features go to the cloud first. Here Microsoft can see if a problem is encountered constantly. Being an On-Prem shop we don’t send data back to Microsoft and only raise an incident if its really bad. This means that more bugs get seen now and fixed so expect more fixes in at least the first year of CU’s especially as more shops move up to the new release.
Chris
I have been one of those that never rolls out a new version until after the first service pack. I have done this for many versions. This logic worked with Microsoft’s previous SDLC. Given that has completely changed and now includes their use in Azure which may or may not be a named version as it being used their prior to non-cloud versions, I am not sure that waiting for CU12 for non-cloud rollouts is equivalent to waiting on SP1 in the old SDLC. I am also not convinced that what microsoft is now releasing as its name year version (Microsoft 2017) is the equivalent of named year versions in times past. I am thinking that CU12 may be overly conservative in this SDLC by a factor of 12. Of course, only time and experience will tell.