Patching SQL Server is an ongoing process. Service packs and cumulative updates are being regularly released in order to apply possible bug fixes as well as provide additional functionality.
This article, suggests a procedure for patching a standalone SQL Server instance. So here’s the suggested procedure:
First on the TEST Environment:
- Plan ahead – inform application owners – get approvals
- Stop all application/services that connect to the SQL Server instance
- Backup server (OS)
- Backup all user databases
- Backup the system databases: master, model, msdb
- Backup the resource database via file system – copy files to a safe location (use the query in the appendix below to find resource database’s files location)
- Install patches
- Reboot server
- Make sure that SQL Server and related services are started
- Start application/services that connect to the SQL Server instance
- Certify that everything works well on the Test server after the installation of patches is completed.
- You need to get acceptance by all affected parties (i.e. IT users, application owners, etc.).
- If there is a problem, you will have to troubleshoot in order to resolve it
- In the unfortunate case where you cannot resolve the problem, as a last resort, you can follow a rollback procedure which involves the following but is not limited to:
- Uninstall the patch(es) previously installed
- Restore the system databases as well as the resource database (both data and log files)
- Reboot the server
- Check if everything is back to normal, that is the state of SQL Server just before the patching started
- If there is still a problem, restore server (OS) from the backup taken prior to start the process
- Check if all user databases are OK. If not, restore them from the backup taken prior to start the patching process.
- Check again if everything OK
If everything is OK on the TEST environment after the patching and you have the green light to proceed with patching Production (i.e. approvals/acceptance by business users/application owners, etc.), then you may follow the same steps as above for the Production standalone server (note: make sure you get approval for an adequate amount of downtime and also take into consideration possible unexpected problems during the patching process).
[Appendix: T-SQL Script to Find the Location of SQL Server Resource Database]
USE master; GO SELECT 'ResourceDB' AS DBName , [name] AS DBFile, [filename] AS FilePath FROM sys.sysaltfiles WHERE dbid = 32767; GO
Read also: How to Patch a SQL Server Failover Cluster
Recommended: Check out my eBook on SQL Server Administration.
Rate this article:
Reference: SQLNetHub (https://www.sqlnethub.com)