SQL Server Standard 2016 Service Pack and Cumulative Update [duplicate]

dba.stackexchange https://dba.stackexchange.com/questions/268744

Question

We are currently using SQL Server 2016 Standard Edition with ALWAYS-ON High Availability. We have two different clusters of SQL servers. We need to update it to the latest version of SQL (As per my research Cumulative Update package 13 (CU13) for SQL Server 2016 SP)

Cluster 1 - Currently on Microsoft SQL Server 2016 (SP2-CU4) (KB4464106) - 13.0.5233.0 (X64)

Cluster 2 - Currently on Microsoft SQL Server 2016 (SP1-CU12) (KB4464343) - 13.0.4541.0 (X64)

Query 1 - Can we update SP1-CU12 to directly SP2-CU13

Query 2 - Can we update SP2-CU4 to directly SP2-CU13

Query 3 - What steps should be taken before and after upgrading

Query 4 - What should be the roll-back plan, incase of failure

Any other word of advice or caution for someone doing for the first time will be appreciated.

Was it helpful?

Solution

Query 1: You have to look this up in the release notes. Normally you can do that, but you always need to check the release notes regardless. There is a possibility that it is not possible. Please refer to this link, which will guide you to all the SPs and latestes CUs available, including the release notes.

https://sqlserverbuilds.blogspot.com

Query 2: The same applies as the answer to your query 1.

Query 3: Since you are 'only' (and I say this between quotes, because you always need to plan things very carefully) upgrading to a new service pack/CU combination, not a new version (like from SQL Server 2016 -> SQL Server 2017), it is fairly straight forward. Install the (chain) of service pack(s)and required CU. However:

  1. Make sure you test and document the upgrade path AND the rollback path before you start the upgrade for your production environment.
  2. Since you are upgrading a cluster, make sure the cluster is healthy and you can are sure you can failover without any issues.
  3. It would be advisable to create a baseline prior to the upgrade in order to compare things afterwards. The most easy way to do this is use performance monitor to capture different SQL Server and Windows Server counters over a month or so. This way you can get an insight of your normal workload and compare it with the workload after the upgrade. This can help in determining if the upgrade caused some issues or not. Even when you think there are none, you could be surprised. :-)

  4. Preferably perform the rollout in phases over your development, test, quality and production environment. Do not upgrade all the environments within a short time span, but let every environment run for a week or more, depending on your requirements, to filter out any possible issues. If you do not have a dev, test, quality, production environment, then at least perform the upgrade on a test environment. Maybe you could use Distributed Replay to simulate a production workload to see what the effects are.

  5. Determine if you want to upgrade to the latest service pack. You are asked not give advice based on personal opinion here, but evaluate for yourself if you want to be on a Service Pack that was brought out yesterday and not all issues/ bugs are known. ;-) There were updates that brought SQL Server to it's knees or even... cause corruption... Check how old it is and also check if other people have had issues with it after they deployed it. Just do some plain 'ol Google searching. :-)

  6. Make sure you thoroughly read all the release notes to check if there are any changes that could have a high impact on your environment. For example, discontinued features, new features, etc.
  7. Just take the extra full copy-only backup before you start and put it somewhere safe. Just in case the 3rd party backup software fails the restore... You don't want to explain that to your boss.
  8. Perform a health check prior to upgrading, so you don't upgrade a broken server. Check the logs, check for performance issues, check the backups, Windows Event Viewer, make sure you check if your DBCC CHECKDB ran recently. Although, you should do this by default. You could also use sp_Blitz from Brent Ozar.
  9. Personally I always perform a DBCC CHECKDB directly after the upgrade AND an extra copy-only backup, just to be sure the upgrade didn't cause corruption and you always have the starting point from directly after the upgrade for possible referencing later on.
  10. Don't fool around with VM snapshots, especially on a cluster. They are not backups and could potentially lead to problems with the snapshot/storage/ io performance. It is more an extra risk than a benefit IMHO.
  11. Check disk space prior to the upgrade
  12. Disable backups and SQL Server Agent jobs during the upgrade
  13. Since you are upgrading a cluster, you can perform a rolling upgrade; https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/upgrade-a-sql-server-failover-cluster-instance?view=sql-server-ver15#perform-a-rolling-upgrade-or-update. My strategy is to failover to the second node, to make sure it works, then upgrade the first node, fail back to the first node and upgrade the second node. Be aware that this could mean downtime, since the SQL Server service is stopped on one node and started on the one you fail over to. Some applications can handle this, some not.
  14. Verify the version afterwards to make sure you are indeed on the expected version.

I think there are a lot of checklists out there on the internet and you can actually easily find them. Have you done some more research but posting this question?

Query 4: The rollback plan is uninstall the SP/ CU, but that is only the SQL Server part of it. Make sure that you test the whole scenario.

Is this info usefull?

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top