Starting with SQL Server 2017, no Service Packs will be released. Microsoft now recommend ongoing, proactive installation of CU’s as they become available. You should plan to install a CU with the same level of confidence you plan to install SP's (Service Packs) as they are released. This is because CU’s are certified and tested to the level of SP’s
Read the list of issues fixed.
Don't patch SQL Server on the same day as OS or Application patches (to make it easier to identify the root cause in the event of issues)
Sandbox (First Test)
Make sure you have a viable backup of ALL databases
Disable SQL Agent
Apply the patch to a DBA sandbox server
Restart the SQL Instance
Enable SQL Agent
Run sandbox test jobs
Check the SQL Server Error Log
Sandbox (Backout Test)
Disable SQL Agent
Test backout of the patch
Restart the SQL Instance
Enable SQL Agent
Run sandbox test jobs
Check the SQL Server Error Log
Sandbox (Second Test)
Disable SQL Agent
Reapply the patch
Restart the SQL Instance
Enable SQL Agent
Run sandbox test jobs
Check the SQL Server Error Log
Agree an outage window.
Be sure all dev/test OS/Database/Application versions are close enough to live to be meaningful.
Identify who is going to run (thorough) tests on each dev/test server
Make sure you have a viable backup of ALL databases
Disable SQL Agent
Apply the patch to dev/test server
Restart the SQL Instance
Enable SQL Agent
Handover for testing
Check the SQL Server Error Log
Rolling patch application is a good idea.. patch a Replica, switchover to it, only patch your original server when you're sure you don't need to rollback.
Agree an outage window.
Identify who is going to run (quick) tests on each live server
Make sure you have a viable backup of ALL databases
Disable SQL Agent
Apply the patch to the live server
Restart the SQL Instance
Enable SQL Agent
Handover for testing
Check the SQL Server Error Log
Failed Upgrades & Rolling Back: A patch installation can fail midway, leaving the SQL instance in a corrupted state, which may require a complete reinstall.
Driver Conflicts: Some updates, particularly those involving firmware or storage drivers, can cause catastrophic hardware issues.
OS/SQL Mismatch: Installing SQL updates simultaneously with Windows OS updates can cause conflicts.
Startup Failures: A patch might cause the SQL Server service to fail to start, preventing applications from accessing the database.
Cluster Failures: In Availability Groups (HA), improper patching sequences can lead to failure to re-join the cluster.
Failed Updates in Prod: Patching during active SQL agent tasks or when databases are in use can lead to corruption.
Pending Reboots: SQL setup often fails if a previous Windows update is pending a restart.
Corrupted Master Database: In rare cases, patch installation can fail during the upgrade of system databases, causing major downtime.
Test in Non-Prod: Always test patches in a development or QA environment first.
Backups: Take full backups (and VM snapshots) before applying any patches.
Check Services: Ensure SQL Agent jobs are disabled before patching.
Wait for Stability: Don't apply the latest Cumulative Update immediately; wait a few weeks for feedback.
To minimize risks, always review the Microsoft Knowledge Base (KB) article for the specific patch, as it lists known issues.
GDR updates – cumulatively only contain security updates for the given baseline.
CU updates – cumulatively contain all functional fixes and security updates for the given baseline.
In SQL2017+ GDRs will use specific CUs as a baseline.
i.e. apply a CU, apply a GDR for that CU, later apply the next CU (which will include the GDR)Be aware of what might be happening on your SQL Server during your patching window. e.g avoid backup windows, scheduled checkdb windows.
Also be aware of the impact on Always On Availability Groups if the scheduled patch performs a reboot.
Be sure of your backout plan. If the patch automation has unexpected consequences, what will you do?
Potential Automation Tools
(These are not recommendations; just tools I am aware of)ManageEngine Endpoint Central
BMC TrueSight Server Automation (TSSA)
SolarWinds Patch Manager
DBAtools (PowerShell)
SSCM
Tanium
"You can't first install the OS updates and then the SQL Server update without a reboot in between. SQL Server Setup has a check that raises a red flag if there are pending reboots. (That is, pending file renames.) So if you are looking into to reduce the number of reboots, you need to try with installing the SQL Server update before the Windows update." Erland Sommarskog (1)
However...
"There is unlikely to be any prerequisite for a Windows update that requires specific SQL Server updates to be applied because not all Windows Servers run SQL Server, however, it is possible that you may need a specific Windows update for a given SQL Server update (none spring to mind but it is conceivable). So given this, applying Windows Updates first is probably your best bet.
NOTE: Windows updates often set the restart pending flags and this can cause SQL Server update installers to fail the prerequisite checks. You need to orchestrate your patching process to handle restarts between applying patches if required." HandyD (2)
TODO