Last November marked the 20 year anniversary of Microsoft’s Patch Tuesday. Like brushing your teeth or taking showers, keeping your SQL Server patched is good hygiene and a best practice. Let’s explore why in this post.

Feature Image Attribution

The Importance of Patching

Typically, after 5 years Microsoft software falls out of Mainstream support and into Extended support for another 5 years. After this 10 year period there are usually no more patches of any kind issued. This is extremely important for those running software out of extended support with security vulnerabilities.

What is Patch Tuesday?

For the past 20 years, every 2nd Tuesday of each month Microsoft releases CUs, security updates, and other patches for their product suite.

The regular and expected release schedule helps for heathly DBA habits. Similar to how the government can set a standard or precedent that private industry follows (ex. CMS – Medicaid / Medicare), large influencial corporations can inspire standards to an industry. Microsoft started 2 decades ago by making a well-known cadence of patching releases e.g. service packs and cumulative updates. Others have followed suit.

Bill Gates wrote a famous memo to Microsoft employees about this. He gives the reasons for Trustworthy Computing in Microsoft software.

Should You Patch SQL Server?

Let’s get into some reasons why you should patch your SQL Server database instance.

• Security – protection from known security vulnerabilities
• Bug fixes – yes there are bugs in software of which SQL Server is not immune
• Performance Optimizations – some patches include new features or performance enhancements
• Compliance – either corporate mandate or necessary if you open a support ticket with Microsoft

Security fixes are probably the most important reason to apply patches. This is especially true of SQL Server versions in extended support. Even if there are no new features, enhancements, or other improvement you will still want patch the instance just for security threats.

Additionally, if you are running SQL Server on-prem either on physical servers or VMs you will need to apply Windows Server patching as well. If you are using Azure SQL Managed Instance then it is automatically handed for you.

When Should You Patch SQL Server?

The short answer is as soon as you can.

The long answer explores your specific scenarios. Generally Microsoft recommends applying CUs ASAP. Start with your development servers and then move on to the QA / staging / DR / pre-prod servers then finally to PROD. This allows you to catch any problems before they hit PROD. Moving a patch sequentially through your environments buys you some time in case there are problems with the patch.

In general, I recommend patching SQL Server within a 2 weeks period of its release.

What About Zero Day Patches?

Fortunate for us, zero-day exploits are patched outside of the Patch Tuesday cadence. When this happens, Microsoft will issue an out-of-band security update ASAP. There’s a security assessment based on various factors to consider:

• Severity – just how bad is the vulnerability?
• Spread – how communicable is it?
• Technical Complexity – how difficult would it be for a bad guy to use?
• Deployment Considerations – how hard is it going to be to apply and get out into the wild?

Regardless, there will be reproduction with a fix coupled with testing.

Reasons Not To Apply a Patch

There are some considerations and scenarios where you might not want to patch or patch right away:

• Downtime – patching a SQL instance may incur downtime by having to restart the SQL Server service or reboot Windows Server. The counter to that is the high availability features which make this point less or not at all a problem.
• Regulatory or corporate policy – sometimes your organization has rules for patching servers and the testing that needs to be done before applying in PROD. Although well intentioned, this is often a stall tactic and can be a bad practice.
• Compatibilty concerns – I’ve seen issues where a company doesn’t patch their SQL Server because some 3rd party COTS application won’t *support* it. The rationale they typically give is they didn’t test it on the build so they cannot guarantee they support it. Push back on this where you can.

These bullet points can usually be mitigated through best practices and testing. They shouldn’t be an impediment to keeping your servers and software up to date.

Another thing to think about it your rollback strategy should you need to. That is to say, if something went wrong while patch how would you return the systems to the operational state they were in prior to applying a patch?

Conclusion

I’m on team “patch your SQL Servers as soon as you can”

In conclusion, patching your SQL Server database instances is not just a best practice—it’s essential for maintaining the security, stability, and performance of your systems. Regular patching helps protect against known security vulnerabilities, addresses bugs and performance issues, and ensures compliance with industry regulations. While there may be considerations and challenges in the patching process, such as downtime, regulatory requirements, or compatibility concerns, these can often be mitigated through proper planning, testing, and adherence to best practices.

I recommend applying any patches for Windows Server or SQL Server as soon as you reasonably can. In the vast majority of cases, the pros of patching outweigh the cons. Remember, just like brushing your teeth or taking showers, keeping your SQL Server patched is good hygiene—it’s a habit worth cultivating for the health and security of your database infrastructure.

You know what else is on the 2nd Tuesday of each month? The blog party #tsqltuesday! If you read about SQL Server and are interested in the Microsoft Data Platform you may consider joining the party by writing a blog post. If you do get one started, throw me a comment and I’ll add it to my feedly RSS feed to cheer you on.

Thanks for reading!

---

You Might Also Like