The Time to Patch

Microsoft has spent years working on building a reliable and dependable patch process for their software. While some products have had more sporadic updates, SQL Server has moved to a fairly regular schedule. Not quite a predictable “Patch Tuesday” schedule, but you can count on a CU arriving every month or two for SQL Server.

Most people don’t patch every month, but slowly customers are getting used to regular patches for SQL Server. Microsoft would prefer you use one of their “evergreen” releases, where Microsoft is in control of patching. Azure SQL Database, and Managed Instances are handled this way, but with Azure Arc, you might deploy these inside of your data center and not worry about patching anymore.

Most of us won’t get there anytime soon, and we will need to patch our instances. This week, I’m wondering about your patching process. Not whether you patch or not, but rather the extensiveness of your patching when you do decide to apply a CU.

If you decide to patch a particular version in your environment (2016, for example), how long does it take you to patch all your SQL Servers? Do you even get all systems patched, or are there always lingering systems that can’t be updated because of some dependency?

Maybe one other question might be how long does it usually take you to decide to patch your systems to some level? Or do you just randomly patch instances as needed?

I am a big fan of leaving systems alone that are running well, but it seems the quality of patches from Microsoft has improved over the years. I’m not quite sure I’m at the point where I want to patch everything to month a CU is released, but I do think a regular process is a good idea, and hopefully it’s one that completes all instances for a version in less than 30 days.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

5 Responses to The Time to Patch

  1. Frank Henninger says:

    Typically, I try to get a patch scheduled quarterly, On the first business day of a quarter, I’ll schedule a patch in the dev environment using the latest CU available on that day. The goal is to have the patch released to production by the end of the quarter. The long time is solely based on my businesses validation requirements. Testers need to be scheduled since not all unit testing is automated.

  2. rsterbal says:

    Have you ever tried this reporting tool?

    https://www.nirsoft.net/utils/windows_updates_history_viewer.html

    are the SQL Patches listed?

  3. Chris Wood says:

    I got permission to patch twice a year and when a security patch comes out that could affect us – there seems to be a few more than there used to be nowadays. Also if we raise an incident with Microsoft it would be stupid not to patch if they provide one. We have 4 environments (DBA/DEVL/UAT/PROD) so its close to 2 months from start to finish with following closely on Twitter to see if any problems arise for others. I always check the KB to see what comes out that affects us. We are around 60+ SQL servers now

Comments are closed.