A Patch Disaster

This isn't the dialog box you want to see on a server.

This isn’t the dialog box you want to see on a server.

Can you imagine sending the wrong patch to the wrong machines? That’s what happened with an Australian bank. Am OS patch was sent to many more machines than it should have. The patch was designed for desktops, but managed to get deployed on servers and resulted in some sort of software corruption.

SQL Server users are fortunate that we rarely have security patches for our platform. There are cumulative updates every other month, but the majority of them aren’t aimed at SQL Server, and many of them may not even be required for the host Windows OS. Your organization’s policy may require the OS patches, and if they do, you should be aware of when and how they are being deployed.

Even if patches are not supposed to be deployed to your servers, you should plan on being aware of the deployment date. You never know when an administrator will make a mistake and deploy a patch to your database server and necessitate a restore. I would recommend that you double check your backups and ensure restore scripts are handy on any patch day.

Our computer infrastructure becomes more complex all the time. At the same time, many of us become more specialized, working in a more focused area, and counting on others to manage the parts of our system we do not have time to worry about. People will make mistakes, and we should ensure we can recover our systems from those mistakes.

Steve Jones

The Voice of the DBA Podcasts

We publish three versions of the podcast each day for you to enjoy.

About way0utwest

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