Stairway to SQL Server Automated Database Testi ng Level 1: Why You Need TDD (2022-12-14)

Daily Coping Tip

Offer to help someone who is facing difficulties now

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Upgrading SSC

The decision to upgrade database servers can be a complicated one that involves features, costs, and support requirements. While I think many people would love to run database systems for ten years, often there are concerns about support, which effectively ends after five years for SQL Server. While you can purchase extended support, is that worth the cost? A hard question to answer, but one I've had to confront lately. When do you upgrade a database instance?

I've discussed this with a few customers, but it also came up in the context of SQL Server Central. We run a SQL Server 2016 database on Windows Server 2016. Someone recently sent a note that since 2016 is out of support, they'd like to upgrade the systems. They were thinking SQL Server 2019 on Windows Server 2022, but with the release of SQL Server 2022 that doesn't make sense.

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.

I think many DBAs would feel the same way, looking to test and certify SQL Server 2022 for their internal apps. This is one reason why getting the RC0 and RC1 releases of new versions for some initial testing make sense. The sooner you can upgrade in version's lifecycle, the longer before you do it again. Of course, if you have more than 50 servers, you might just be upgrading every year anyway, as some system is always falling out of support.

Upgrades take time. There's the time considering the decision, the testing a new system, the actual upgrade time, whether in place or migration, all of which eat up labor and time. Doing this for more than a few servers can become a full time job in some cases. That makes me start to really see the wisdom of using a PaaS service that's evergreen.

For organizations where support matters, then upgrades are a fact of life and a regular occurrence. However, if formal support isn't an issue, you might feel differently. The more mainstream you keep your feature usage, the more likely that you can go far past 5, or even 10 years, with your database system. I know there are still companies running 2008, 2005, and even a few 2000 servers. I don't know that the SQL Server Central code would run on SQL Server 2000, but it might. Project Nami is using fairly generic SQL. If we were more concerned about database licensing, likely we'd have not upgraded the site from ASP.NET to WordPress.

For now, I think we'll likely upgrade sometime in early 2023. I am not worried if things are delayed, but I do know that we also want to upgrade both WordPress and PHP and there is an order to getting all these steps completed. Because of this, I want to ensure that we proceed soon and get things moving while my schedule is fairly light so that I can test and deal with any issues that arise. Hopefully there won't be any, but I've learned to hope for the best and prepare for the worst, especially with software upgrades.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums