SQL Server Patching Best Practices

It’s day four of the two weeks to a healthier SQL Server series. If I were making this ten-day plan even just three years ago, I would have had this lower on the list. With the security and compliance needs of the world today and the way Microsoft services SQL Server – it’s important to have a good rhythm for patching SQL Server. And understand some of the frustrations and make sure your SQL Server patching strategy is holistic.

What Happens if you Don’t Patch SQL Server?

If you don’t patch your SQL Servers – critical fixes to known issues will be missed by your organization. You’ll miss security updates and patches to keep you compliant and protect your data. And if you make your auditors and CISO mad, well, good luck.

But if you patch too soon – you risk being hit by an “oops” of a bad update.

Let’s discuss…

How to Check Your SQL Server Patch Level and What’s Available

Pretty simple. But, in typical Mike Walsh fashion – I have a slightly deeper blog post about SQL Server versions…

The simple version – Just run

SELECT @@Version

Look at the numbers.

Go to the “definitive” SQL Server Builds list that someone somewhere has been maintaining forever (Thank you, whoever you are!) And check. Are you current? Or not? How far back are you? See more below, first.

I also really like the SQL Sentry/SQL Performance SQL build tracker – they have a nice chart that has historically shown when a patch was pulled and why so you know to maybe, you know, skip that update if you have previously downloaded it.

A WARNING on SQL Server Patching!

Here at Straight Path, we have a policy for patching we use with most of our Remote DBA Services clients – Current, but not bloody edge. We’ve seen enough patches pulled because of critical misses lately that we want to let all you other aggressive patchers get burned first. It’s not that we don’t love you – we just love our clients more.

We tend to do a process that looks like this:

• Is the patch at least 1-3 months old? We’ll patch it for sure if we don’t see folks complaining about it.
• When the next patch comes out – we’ll apply the previous one.
• We read the KB articles from Microsoft about the patches and see if a client is really burned by a bug out there in their current patch level that’s been fixed by the previous patch – we’ll make an exception and patch them if they are fixed by it.
• If they are getting stack dumps of unknown origins – we will typically bring them to the latest and greatest patch level to see if the stack dumps still happen. and if they do – we’ll call Microsoft knowing that at least we did that since, well, you know.

Homework

• Check your patch levels
• Compare to one of the two build lists
• Plan to patch your SQL Servers
  • Dev/Test/Staging first if you can
  • Not the latest unless it is 1-3 months old, fixes an issue you are experiencing or is a critical security update (or once a newer patch comes out, go with previous CU – so long as that new CU doesn’t fix issues in the previous CU, that would be a bad idea.)
• Patch your SQL Servers

What about SQL Server Service Packs?

This is a different situation, I’d say. Starting with SQL Server 2017, Microsoft changed their servicing model – no more Service Packs for SQL Server 2017, 2019, and SQL server 2022 (coming soon). Only CUs for those versions of SQL Server.

So if you are on SQL Server 2016 or SQL Server 2014 – go ahead and get yourself service packed to the latest.

If you are on SQL Server 2012 – let’s get that upgrade going! (but at least service pack).

If you are on SQL Server 2008, c’mon, I mean… Check out the fun site we built about SQL Server 2008 here – counting down to (and since) the End of Life.

And check out our webinars and material on how to perform SQL Server Upgrades.