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 how to patch a standalone SQL Server instance.
First Patch SQL Server on the TEST Environment
First, always patch the respective SQL Server on the Test environment.
Here’s the suggested procedure:
- 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
When to Proceed with Patching SQL Server on Production
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).
Tip: T-SQL Script to Find the Location of SQL Server Resource Database
By running the below T-SQL script, you can find the location of the Resource Database of your SQL Server instance(s).
USE master; GO SELECT 'ResourceDB' AS DBName , [name] AS DBFile, [filename] AS FilePath FROM sys.sysaltfiles WHERE dbid = 32767; GO
- How to Patch a SQL Server Failover Cluster
- How to Add a Database to a SQL Server Availability Group Using T-SQL
- Top 10 SQL Server DBA Daily Tasks List
- The “Public” Database Role in SQL Server
- Encrypting a SQL Server Database Backup
- Learn Azure Data Lake Analytics by Example
- Azure Cosmos DB: Learn by Example
- How to Create an Azure SQL Server Virtual Machine
- How to Backup a SQL Server Database from On-Premises to Azure Storage
- … all our SQL Server Administration Articles
Featured Database Security and Administration Tool: DBA Security Advisor
DBA Security Advisor: Secure your SQL Server instances by scanning multiple instances against a rich set of security checks, and by getting recommendations and remediation steps.
Did you find this article useful and interesting? Feel free to leave your comment!
Subscribe to our newsletter and stay up to date with our latest articles on SQL Server and related technologies!
Check out our latest software releases! All our software tools have 30-day Trial Versions which are free to download.
Rate this article:
Reference: SQLNetHub.com (https://www.sqlnethub.com)