December 14, 2022 at 12:00 am
Comments posted to this topic are about the item Upgrading SQL Server Central
December 14, 2022 at 1:45 pm
I've been a DBA 10 years at 4 different companies now and they all have purchased the extended support (usually via SA), effectively giving the product a 10 year shelf life. I can't imagine worry about upgrading every instance every 4+ years.
December 14, 2022 at 4:38 pm
Our line has always been the loss of extended support. We've got enough prepaid support hours built into our enterprise agreement to cover the once every three years or so I need to call MS support over a SQL issue. If it weren't for security patches going away with extended support we would probably run many SQL boxes longer than 10 years. Trying to keep everything on general support levels would require us doubling the size of our DBA team with the new guys doing nothing but upgrades. Not an effective expenditure.
December 14, 2022 at 6:19 pm
Interesting. I know sometimes for compliance reasons, you need to show support. For me, my view has usually been security patches still come, so if it's been working for 4-5 years, I stop worrying and expect it to last 10 years.
In the SQLServerCentral history, we were SQL 2000 for a long time, then finally SQL 2016, now looking to move again. I think we could still run on 2012 (not sure about 2008R2-), and be fine.
December 14, 2022 at 6:38 pm
I spent much of the first half of this year doing upgrades to get off SQL2012. Was mostly successful by the deadline, the exception being about 25 servers which were either running an application being decommissioned before the end of the year or running a vendor supplied application which couldn't run on a newer version. Still waiting on the vendor for 18 of those servers to supply the fix they promised in the 3rd quarter to allow the SQL upgrade.
December 15, 2022 at 1:46 pm
I go to the dentist a couple of times a year. If I'm lucky, he doesn't find anything dire and I get a good cleaning out of it. It's not something I look forward to. Database upgrades are like that.
Are you considering going to something like Azure SQL DB? That would get you out of the upgrade cycle completely. If you're not, I'm curious why.
December 15, 2022 at 2:13 pm
I want to defer this process as long as possible. To me that means always aiming for the latest and greatest version. SQL Server releases roughly every 2-3 years, so this is the best time to upgrade for us. If we can upgrade before 12 months, we get 4+ years before we revisit this topic. If we were to upgrade to SQL Server 2019, then we're already down to 2 years of support before we need to consider the topic again.
Pretty much unless there's some compelling technical reason to upgrade. In the past the decision (partly me) was made to "stick with what we know" for a large project and in hindsight was a poor decision. We stuck with 2008R2 instead of 2012 which was just being rtm'ed. Because of that decision I "missed" (didn't have access to instance(s)) SQL Server 2012 and 2014
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
December 15, 2022 at 3:33 pm
I go to the dentist a couple of times a year. If I'm lucky, he doesn't find anything dire and I get a good cleaning out of it. It's not something I look forward to. Database upgrades are like that.
Are you considering going to something like Azure SQL DB? That would get you out of the upgrade cycle completely. If you're not, I'm curious why.
worth considering, though for us, we are in AWS, so crosstalk between clouds wouldn't be great. We could move, but lots of infrastructure is in AWS for us, so that would be a larger-scale piece of work. We could use RDS, but that's not evergreen. Someone still has to patch.
December 15, 2022 at 10:30 pm
running a vendor supplied application which couldn't run on a newer version. Still waiting on the vendor for 18 of those servers to supply the fix they promised in the 3rd quarter to allow the SQL upgrade.
I would be interested in knowing why the appplications would not run on a newer version of SQL Server. We have a number of old applications which have been running okay for four years on SQL2016 and SQL2017 with the database in compatability mode of 100 (SQL2008). At the time we did the upgrade there was a lot of regression testing and we could not find any problems; maybe we were lucky.
December 15, 2022 at 10:51 pm
After the vendor stated there is no support for running that version of their application on a version of SQL later than SQL2012, the application support team set up a test box running SQL2016. I wasn't directly involved with the testing but was told that several key modules of the application simply would not work regardless of the compatibility mode setting. My guess is that it is using some deprecated syntax in stored procedures. This is an old version of a very old application. It hasn't been upgraded because the version after the one we use has stability, performance, and feature loss issues. The version we will be migrating to is three versions later, but had a show stopper bug in a module critical to us. So we await a fix.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply