What the New SQL Patching Cycles Actually Mean to You

At Microsoft Ignite, Microsoft announced that they are changing the patching cycle for SQL Server. SQL Server will no longer release Service Packs for SQL Server 2017, instead of releasing only CUs and releasing them much more often.  CUs will be released monthly for the first 12 months of a new release, then quarterly after that.

Now some people out there in blogger world have gotten cranky about this.  But this new patching model is a good thing.  The scariness to CUs for years has been that little disclaimer attached to them, stating that they should only be installed when you are impacted by an issue that the CU specifically fixes.  This disclaimer was there because in the dark ages of SQL Server (SQL 2005 or so) CUs weren’t as well tested as Service Packs, they just couldn’t be because the automation wasn’t there to do so. This warning was recently (in the last year or so) removed–CUs go through the full testing cycle that SPs and RTM releases do.

Now the automation is there to do the testing.

Because of this, we don’t need Service Packs, because every CU is now effectively a Service Pack.  The fixes are going to be coming out faster. This doesn’t mean that there are more bugs that need to be addressed, or that the software is more unstable or any of the other conspiracy theory nonsense that I’ve read about this.  It simply means that along with the faster release cycle that we saw for SQL Server 2017, Microsoft has accelerated the release cycle for patches as well. This resembles Azure SQL Database–doesn’t it? (hint, hint)

This all means that if there is a bug in the software that impacts our systems that we have to wait for, this means that we will get the patch faster than we’ve ever gotten the patch before. And without having to open a support ticket and get a hotfix patch. We get this via a fully supported CU patch through a normally supported servicing release.  This sounds like a good thing to me.

Does this mean that you need to do more patching of SQL Server? Maybe.  If you want every possible patch installed to get every possible fix, then yes. But you probably aren’t hitting every possible bug that’s fixed by every possible CU that comes out. If you are you are either pushing the product harder than 99.9% of the users out there, or you are one unlucky shop.

I’d recommend patching SQL as often as you can. If you can patch each month for that first 12 months, excellent. If you can’t get a monthly maintenance window to get those CUs installed, then shoot for every other month.  If you aren’t being currently affected by an issue that’s being resolved by a patch, then waiting for an extra month won’t kill you, and if you are, then getting the patch faster than you would have gotten it under the old servicing model and getting the maintenance window to get it deployed really shouldn’t be that big of a deal. This is best time to build some automation into your patching solution.

Denny

The post What the new SQL patching cycles actually mean to you appeared first on SQL Server with Mr. Denny.