July 8, 2024 at 12:00 am
Comments posted to this topic are about the item An Upgrade Slog
July 8, 2024 at 8:06 am
Can't you use Redgate SQL Backup to do restores that are no longer possible with native SQL backups? I think, I did this some years ago with SQL 2005 to 2014 if I remeber correct.
Another way may be to recreate the tables / procedures / views etc. in a new database and copy the data with linked server. The old databases are often not that big, since disk space and memory were much more expensive 20 years ago.
God is real, unless declared integer.
July 8, 2024 at 8:35 am
I have been hunting for a pyramid diagram that represents the pace of change for the different layers of applications.
The fastest layer is at the top representing the user interface. There are several layers with Infrastructure being the slowest changing at the bottom with the database 2nd to bottom.
The squeaky wheel gets the oil. The lower layers tend not to squeak though I wish they did. I don't think DBAs these days can ignore what happens in the layers beneath the DB. I think we need to be aware of obsolescence in the layers beneath us and if those layers are trying to squeak, add our voices to make sure the impact is not underestimated. After all when the lower layers break they can be hardest to resolve and they all affect the layers above.
If you run infrastructure as code, don't forget to keep whatever you are using up-to-date too otherwise you can find yourself forced to upgrade rather more than you expected.
I've spent a lot of time upgrading old versions of Terraform. Terraform provides a wrapper around an API, could be a cloud provider, could be GitHub, Databricks, Snowflake etc.
An old version of Terraform may only support a cloud provider APIs up to a certain version. The Terraform provider may only support facilities in the that particular cloud up to a certain version and will also be completely unaware of cloud facilities released since that cloud Terraform provider was released.
The situation I found myself in was when the cloud I was using notified me that the version of Python being used was to be deprecated. The Terraform cloud provider only supported up to the version being deprecated so suddenly I found I needed to upgrade Terraform and upgrade all the apps running that version of Python. There are a lot of differences between Terraform today and the old version of Terraform so that upgrade is non-trivial. On top of that there are library changes and CVEs for Python have an impact on that upgrade. Two major upgrades that had to be carried out at once. Never a good idea.
July 8, 2024 at 4:05 pm
Been a few years since I've done a multi-restore version upgrade, but there was a couple years where it happened often enough that I had a virtual box spun up running SQL2005 just for that interim step. As always the gotcha on managing versions is always vendor software compatibility. Industrial process control software in particular often lags significantly on it's version compatibility. I've still got 18-20 instances of SQL2012 (on Windows 2012) out there because that is the newest version one particular vendor software module will support. When that sort of thing happens you have to mitigate as best you can. Firewall off the offending boxes from the rest of the network, only allow connections from specific IPs, and be sure you have verified good backups.
July 8, 2024 at 4:33 pm
Can't you use Redgate SQL Backup to do restores that are no longer possible with native SQL backups? I think, I did this some years ago with SQL 2005 to 2014 if I remeber correct.
Another way may be to recreate the tables / procedures / views etc. in a new database and copy the data with linked server. The old databases are often not that big, since disk space and memory were much more expensive 20 years ago.
No, there's no magic in any third party tools. You are limited to what MS supports. Which for 2014 (docs are offline now) was likely 2005. Might have been 2000, but probably not. SQL 2016 goes back to 2008. 2022 only goes to 2012.
July 8, 2024 at 4:34 pm
I have been hunting for a pyramid diagram that represents the pace of change for the different layers of applications.
The fastest layer is at the top representing the user interface. There are several layers with Infrastructure being the slowest changing at the bottom with the database 2nd to bottom.
The squeaky wheel gets the oil. The lower layers tend not to squeak though I wish they did. I don't think DBAs these days can ignore what happens in the layers beneath the DB. I think we need to be aware of obsolescence in the layers beneath us and if those layers are trying to squeak, add our voices to make sure the impact is not underestimated. After all when the lower layers break they can be hardest to resolve and they all affect the layers above.
If you run infrastructure as code, don't forget to keep whatever you are using up-to-date too otherwise you can find yourself forced to upgrade rather more than you expected.
...
A good reason to not add too much complexity to your environment. It adds lots of admin work to keep patched.
July 8, 2024 at 4:36 pm
Been a few years since I've done a multi-restore version upgrade, but there was a couple years where it happened often enough that I had a virtual box spun up running SQL2005 just for that interim step. As always the gotcha on managing versions is always vendor software compatibility. Industrial process control software in particular often lags significantly on it's version compatibility. I've still got 18-20 instances of SQL2012 (on Windows 2012) out there because that is the newest version one particular vendor software module will support. When that sort of thing happens you have to mitigate as best you can. Firewall off the offending boxes from the rest of the network, only allow connections from specific IPs, and be sure you have verified good backups.
Firewalls are definitely your friends, and honestly, I wish vendors would be forced to support upgrades for databases to some level when there are potential security problems. There might be issues, but often there aren't and they just don't test on newer versions. Unless they use a keyword, I'd think at least 2016/2017 would be supported
July 8, 2024 at 4:36 pm
Been a few years since I've done a multi-restore version upgrade, but there was a couple years where it happened often enough that I had a virtual box spun up running SQL2005 just for that interim step. As always the gotcha on managing versions is always vendor software compatibility. Industrial process control software in particular often lags significantly on it's version compatibility. I've still got 18-20 instances of SQL2012 (on Windows 2012) out there because that is the newest version one particular vendor software module will support. When that sort of thing happens you have to mitigate as best you can. Firewall off the offending boxes from the rest of the network, only allow connections from specific IPs, and be sure you have verified good backups.
Firewalls are definitely your friends, and honestly, I wish vendors would be forced to support upgrades for databases to some level when there are potential security problems. There might be issues, but often there aren't and they just don't test on newer versions. Unless they use a keyword, I'd think at least 2016/2017 would be supported
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply