SQL Server Service Packs are going away, starting with SQL Server 2017. I talk about why I think this is a good thing, and discuss Cumulative Updates, Service Packs, and the process of updating SQL Server.
No time to watch right now or read the transcript below? Listen in podcast format on iTunes , on Google Play, or plug this RSS feed into your favorite podcast app: http://dearsqldba.libsyn.com/rss
Transcript of this episode
Please forgive errors in grammar and punctuation: robots drafted this transcript. And then I “fixed” the draft, which can go either way.
Welcome to “Dear SQL DBA,” a podcast and YouTube show for SQL Server developers and database administrators. I’m Kendra little from SQLWorkbooks.com.
Today we’re talking about the death of SQL Server Service Packs
SQL Server is no longer going to have Service Packs for SQL Server 2017 and future versions.
Service Packs are going away, but for your existing, older versions of SQL Server you’re still going to have Service Packs, just like before. This change is for SQL Server 2017, which just hit general availability, and future versions.
We’re still going to get fixes for SQL Server, it’s just that the support cycle isn’t going to include Service Packs.
I think this is a great change and I’m really glad!
I will not miss Service Packs.
I know that people are used to them, I know that it’s a change, but I think that it’s a really positive change. We will still have Cumulative Updates.
Cumulative Updates used to be kind of confusing and weird
The old story was: years ago when Microsoft released these bundles of fixes called Cumulative Updates for SQL Server, they have this little note on them that read, “you should only install this Cumulative Update if it fixes a problem that you have. We don’t generally recommend applying these all the time.”
This was kind of a weird thing, because when you read the release notes for Cumulative Updates, you see that these fixes are for lots of different issues in the SQL Server. A lot of times you read these issues for fixes and you say, “well we don’t want to have that problem… I am not SURE that we’ve had that problem.. but we certainly don’t want to hit it!”
This would put you in kind of an odd situation, because things could go wrong! You’d want to be proactive and install the Cumulative update, because, hey, say you DO hit the problem. Then you’re like, “well, I happen to know that’s fixed by a patch.” Shouldn’t you have applied the patch to prevent it? Right?
Things changed, and Cumulative Updates are now much more clear
The current story for Cumulative Updates– and this is for your existing version of SQL Server, this isn’t just SQL Server 2017– now if you look at Microsoft’s guidance on Cumulative Updates, they say: we test these a lot, we test these hard, and we think you should test them too. (Because with anything you need to test it.)
But they say you should proactively test and regularly apply Cumulative Updates for your SQL Server instance, which is great.
You do want to be proactive, and you don’t want to be in the position of hitting bugs and then find out that it was released in a Cumulative Update months ago.
So Microsoft — and this was about a year ago that they updated things — said these Cumulative Updates are well tested and they should be part of your patching cycle.
What’s it like to regularly apply Cumulative Updates?
Now the truth is, DBA teams that I’ve been on, even back in the SQL Server 2005 days I remember regularly testing and applying Cumulative Updates.
What we would do is this: we would go through a testing process using development instances and pre-production instances. We’d have known versions of Cumulative Updates that had been through the testing cycle before they moved to production. We would not move EVERY Cumulative update into production, just because the amount of testing that we put them through, but we would frequently move to, “ok we’ve gone through and tested through this version of the Cumulative update, and it is safe for us.”
We would review every Cumulative update that came out, and at times would see mention of issues in there which were critical, like, okay we should get this into the testing cycle quickly, because it sounds like something we’d really want to avoid.
But we wouldn’t necessarily deploy every version of Cumulative Update.
What you choose to do, the frequency that you choose to test and deploy Cumulative Updates, is totally up to you– but Microsoft really encourages you to not wait for Service Packs on your current versions of SQL Server before you apply changes.
Ever been trapped between a CU and an SP?
Part of the reason that I won’t miss Service Packs is, for these current versions of SQL Server where we have Cumulative Updates and Service Packs, you can get into weird positions with them.
Sometimes a bug can be detected and fixed in a Cumulative Update that then doesn’t end up in the Service Pack based on timing.
I don’t know if you’ve ever been in the situation where you’re stuck between a Cumulative Update and a Service Pack, but we’ve had a couple of instances of this.
Something, a bug, was confirmed by Microsoft, and it wasn’t confirmed in time to make the Service Pack release train. But it did make a Cumulative update release train. So you’d get into this situation where if you installed the Service Pack, you weren’t protected from the bug. If you installed the Cumulative Update, technically lower than the Service Pack, you’d be protected from the bug.
What would happen in those situations is usually Microsoft would shortly release a hotfix or a patch to the Service Pack if the bug was important enough. Then you’d finally get out of this situation. But it is just weird and awkward.
Without Service Packs, the service lifecycle for 2017 not refers to Cumulative Update
There are some things that had to be changed, like the the rules about the servicing life cycle for Microsoft.
How old can your SQL Server instance get and still be supported by Microsoft? Questions like that.
Those rules had to do with, “how how long ago was the latest Service Pack you released?” So those have been updated for SQL Server 2017, they’ve been updated to refer to the Cumulative Update lifecycle now. There still is a support lifecycle, it’s shifting to be specific to the Cumulative Updates.
Who will miss Service Packs? Probably Change Approvers.
I personally won’t miss Service Packs. This will, for those change approvers, for folks who’ve been around in IT for a while and are wary, who are like, “we don’t move to a version of SQL Server until SP1 is out” — for those folks, you need to figure out: what’s the equivalent?
If we don’t technically have a Service Pack, is 6 months of Cumulative Updates good enough?
Because Microsoft has announced ok for 2017 we aren’t going to have Service Packs we are going to release Cumulative Updates on a given schedule. We’re going to do it once a month, I think, for the first year. They even give a date for it within the month. And then after that it goes through a different cycle. (Read the details on the SQL Server Release Services blog here.)
So you can say, at the six-month point, we should have six Cumulative Updates. At what point do they feel comfortable?
These days things are really changing, and I think there’s even more to think about rather than just general availability for the boxed product. For SQL Server 2017, many of the features were available in Azure SQL database before we had general availability of the boxed product. So do you start the six months from the point at which people could raise their compat level in Azure SQL Database? It’s really up to you.
I do think that it’s good for everyone if we start phasing this into our environments early. One way to think about this, if you have multiple SQL Servers, is phasing it in on our development instances and our least critical production instance first. Getting really comfortable with it, then going on our more critical instances later. Depending on how you do your licensing, what your options are will vary, of course.
But I do think, yes, there is the change approver who has to adjust if there aren’t any Service Packs — let’s reconsider when we deploy. I honestly think that’s a good thing, because I don’t believe in waiting for Service Pack 1, personally, to deploy.
Now is a good time to review your patching and your upgrade process, and I think it’s a celebration!
Enjoy the fact that Service Packs won’t always be part of our world and that with the life cycle of SQL Server 2017 we can say goodbye to Service Packs.
A quick shout out to all of you who left a review for Dear SQL DBA on iTunes
Your star ratings and your reviews really really help the podcast. I very much appreciate it. Also, for folks who’ve left reviews on the free courses at SQLWorkbooks.com, thank you folks so much. That really helps me build the business, and it helps me continue.
Please consider leaving me a review either on SQLWorkbooks.com, or for the podcast on iTunes.
Thanks, folks and I’ll see you next week.