April 25, 2023 at 1:12 pm
I'm being asked to do an in-place upgrade of both the OS and SQL Server on a physical server.
Currently running -
Windows Server 2016 Standard
SQL Server 2017 Standard Edition (64-bit)
Wanting to upgrade to -
Windows Server 2022 Standard
SQL Server 2022 Standard
Is it recommended to update the OS first or does it matter?
April 25, 2023 at 1:52 pm
I'd say the first thing to make sure of, is that you've got a solid bail-out plan in place, regardless of the order you upgrade. What happens if the OS upgrade goes sideways and the system will no longer boot up, how will you recover? What happens if the SQL upgrade goes catty-wumpus, how will you get things back up and running?
That being said, IF I were being made to do such a process, I'd probably upgrade the OS first, patch it up to current, then (presuming everything is still working,) leave everything alone for a week or two to see if anything crops up. Then tackle the SQL upgrade. Partly, also, doing it OS first means, if the OS update DOES blow up, you've not spent time updating SQL already.
April 28, 2023 at 3:54 pm
I wouldn't do it. There are some pretty major changes in Windows from server 2016 to server 2022. Many drivers are going to have to change especially on a physical machine and remnants of the old drivers are unlikely to ever be totally cleaned up.
I don't think there is any way you can manage your risks unless you plan for an extended outage doing a rehearsed bare metal recovery of the OS - but if you have the ability to rehearse it on spare, equivalent hardware, why not just build a new server and migrate to it? It would be less effort, less downtime and much lower risk.
SQL I don't have many problems with doing an in-place upgrade if I personally know the entire history (going all the way back to when the server was an iso or disk in a sysadmin's hand) of the SQL instance, the server hosting it and what has (or hasn't) been done to that server. Organizations that typically want to do both OS and Instance in-place upgrades however tend to treat those servers like pets and have a long history of workarounds, mistakes and bad decisions.
If it is an option, Server 2019 would pose much lower risk than server 2022, it is more similar to 2019 than 22 is. I still would not count on it being entirely successful and free of 'gremlins.'
The only things you could do to mitigate risks at all would be to go to the server vendor's site, get all the most current drivers and firmware for server 2016, get them installed. Update server 2016 to the most recent available CU. Update SQL to the most recent available CU. Then find all the server 2022 drivers and firmware, get them staged out and as soon as the OS is done, uninstall all the drivers you can from the console then install the server 2022 drivers/firmware.
May 1, 2023 at 6:21 am
I would not do this. If pushed very very hard by my management to do this I would resign.
The risks of having an unrecoverable system are very high. I remember a few years back I built a test environment of three servers from the same system image so that I could test SQL upgrade in place. All the upgrade process was scripted. Two servers upgraded ok. The third failed part way through with SQL left in a state where it would not start.
Upgrading in place can be a 'fun' exercise on a scratchpad system you care nothing about. For a live system the business risk is just about off the scale.
In any reasonably modern IT shop upgrade in place should not be necessary. You would be running your SQL instance in a Hyper-V* guest so moving to a new SQL version would start with a new guest OS.
* Other hypervisors are available.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 5, 2023 at 7:26 am
This was removed by the editor as SPAM
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply