The general easy answer always applies patches, but when.
Here is my process:
- Get notice of patch
- Review the patch details (1-2 hour task)
- If the patch is security vulnerabilities, only apply the patch after 7 days wait. But can patch test servers of that version right away.
- If the patch is not repairing security vulnerabilities only, then apply to a test server first and wait 30 days to review. But the list of features is not always so cut and dry.
- Patch test servers first, and after 30 days, patch production.
For to give you more details on step 2, how do I review the patch details? READ. Seriously, read each and all lines and the detailed descriptions. I rate the line to does it affect our system? (Y/N). I have also maybe to this. The more “Yes’s,” the sooner I apply push for the patches. The more “No’s,” the less I push for it. Each patch takes about 1-2 hours to thoroughly review. To not sound like chicken little, I hardly ever end up pushing for a sooner date. I have attached my spreadsheet for this to help you get an idea of this process.
I note the critical bug fixes for “change control,” so everyone knows why this is important.
I keep a patching spreadsheet with the state of each server. It contains support notifications and if patches are required that month.
If you look closely at this, you will see in the details that the Mainstream support is listed and Extended support. I want to keep this information in people’s faces as much as possible, so they know why I am always harping on the upgrade the servers. Because of the process of patching test servers and waiting, I have the filename and version listed to patch.
On the far right of the full sheet are the contact details of the data stewards and when can the patch be applied from the lookup sheet.
Once I have patched the test servers or am waiting on the patch to be revoked by Microsoft, yes, they do that. I also watch for other bloggers that have had bad experiences with a patch before I apply to patch production.
The main concept to remember is that you do not want to apply the patches first. Nor do you want to apply the patches on production servers without testing them on another environment. If you are like me, you have 2008R2, 2012, 2014, 2016, and 2017 versions of SQL Server. This means we have to 5 times the work to do. And need 10 times the organization to make sure you know who is doing what and when.
See my next blog on Killing off SQL Server 2012 and SQL Server 2014.
If you think this is a hard task? Making your databases secure, reliable, and fast. Want help with your database patch process or to outsource it completely?
