Voice of the DBA

Tag: upgrades

  • Upgrades are Hard

    I think the people that run StackOverflow are pretty sharp. They’ve built a well performing site, they’ve worked on some useful open source projects, and they think through their projects. They still have issues with upgrades.

    Taryn Pratt, from Stack Exchange, has written a few nice posts about her experiences upgrading the Stack Overflow databases. The first one was last year, where their multiple server AG environment upgraded from SQL Server 2012 to SQL Server 2017. Just recently she published another post on their Windows Server upgrade, from 2012 to 2016.

    If you’ve never done a complex upgrade, these posts are worth reading. Don’t second guess Taryn, but rather, just read as if you are following along. You have hindsight now, but in the middle of planning this, you will learn about things that might cause you issues. In the Windows upgrade, one of the interesting issues is a VM vs. physical machine issue with drivers. To me, this might be one reason to never bother with anything other than a VM, even if it’s the only one on the machine. A lightweight version of Hyper-V or Xen doesn’t eat much in the way of resources, but can provide some separation from these issues.

    One other thing to note is that you really need your runbook. I constantly see people asking for a checklist for how to upgrade, and there are good general steps to follow, but your environment likely needs to have a custom runbook that covers your situation. The Stack environment is complex, but even I was surprised with 35 pages of steps and notes.

    As with most plans, this one had issues when it was finally implemented. I think Mike Tyson sums it up nicely, which is why you practice your move. It’s also why we can’t necessarily upgrade every year. There’s a reason many companies still have old versions in production (Thanks, Brent Ozar).

    Plan, practice, test, repeat again, and then be prepared to think on your feet. That’s if you upgrade your systems. It’s time consuming and expensive, and I can see why a lot of companies have looked at cloud services, like Managed Instances. Reducing the time and cost to change your OS and/or SQL version is something we should all be thinking about.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Waking Up to No Support

    When you wake up on July 10, SQL Server 2008 and 2008 R2 will be out of support. Microsoft has been talking about this for some time, there’s been a Migration Tour from PASS with live events in quite a few cities, webinars, and more to let you know that you might want to upgrade to a supported version.

    While I typically think that systems that run are fine and don’t necessarily need support, there are compliance and security concerns here. If you work in a regulated industry, you might need support to stay compliant. If that’s the case, you might want to ensure you have plans to move to SQL Server 2017 (or 2019) soon.

    The same goes in this era of attacks and potential security issues. While SQL Server has relatively few patches for security, you never know. I haven’t worried about this in the past, often with internal servers, but I do get more concerned over time as we seem to constantly find more complex bugs in hardware and software.

    SQL Server 2008 support is over, but you have options. Microsoft will continue to support you if you move your servers to Azure. That’s not a bad option if you need to move quickly, but don’t forget to really think through what this means for your applications. Moving to Azure isn’t necessarily as smooth or simple as you might think. Authentication and authorization need some attention to detail to get working well. It’s not hard, but it is work.

    When SQL Server 2005 went out of support, it didn’t seem there was as much emphasis on migrating. Certainly lots of people ran SQL Server 2000 instances for many years without support. You can do it, but the world feels more dangerous, and there are more implications with regard to regulation, security, insurance, and other complex topics that can impact your business.

    Think carefully about the implications of migrating and not migrating. You’ll have to make the decision, and it can be hard, but it’s something you should spend quality time thinking carefully about.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Minimum Upgrade Point

    These days the pace of change with SQL Server can be intimidating. Many of us work in disparate environments with multiple versions of the platform in our environment. In the distant past I’ve had people note that they often have 2 or 3 versions to support. In the last five or six years, when I’ve asked it seems that many people have 5 or 6 versions to support. That can be challenging in trying to manage your estate as a single entity and understand which scripts will run on which machines.

    Recently someone noted on twitter that they tried to convince their company to upgrade to SQL Server 2017, but apparently someone at the company wanted to stick with SQL Server 2014. I asked a question and the person responded that since Dev and QA was at the 2014 compat level, they wanted prod there.

    Pedro Lopes, from Microsoft, asked a good question: “How can I help you avert this?” I tend to agree, in that moving to 2014 now, which will fall out of mainstream support in July 2019, is silly. You’re installing a system that will be unsupported almost from the beginning. While you will get security patches for a few years, it seems short sighted to start using a version that you may want to use for 10 years.

    That got me thinking. What is the minimum upgrade point for your organization? Not the pace or the need, but if you had to pick some random instance to upgrade, where would you go? SQL Server 2017? Something sooner? Perhaps you have some requirements in your organization that limit you from moving to a very new version. I would argue that it’s important dev/test are similar to prod, but I’d also say that dev and test ought to upgrade to a recent version as well.

    I think I’d specify SQL Server 2016 SP1 as the minimum point. This changed the feature list in Standard Edition, which is what I’ve often run for systems. We run that now for SQLServerCentral, though our decision last year was a move to 2017. We probably won’t upgrade again for many years, but if we did, I think I’d be looking to get close to the most recent version.

    What would you do?

    Steve Jones
    Listen to the podcast at Libsyn.

  • The Upgrade Storm

    The Perfect Storm is a movie about the confluence of three weather events that combined to create a situation the resulted in the loss of all life on a fishing boat. It’s a good movie, and certainly one that might make anyone think twice about sailing off into the North Atlantic in bad weather. I certainly wouldn’t want to be traveling on the water when any type of hurricane might present.

    Glen Berry writes about a perfect storm of a different sort. The perfect storm to upgrade, with the confluence of three events he sees taking place soon. We have quite a few performance related changes coming in Windows 2019 Server, in CPU hardware, and storage technology. Those three changes could dramatically improve the performance you might see from your SQL Server licenses.

    If you were planning on updating a legacy system with a new version of SQL Server, you might do well to consider some of these hardware and software improvements. I don’t know what the costs might be, but that’s certainly something you will have to consider for your environment. The argument likely would be that if you’re updating the database server, why skimp? This is a limited resource and one that can affect your entire system. Spending some money here might make a significant difference to the way in which your system performs.

    This might be a perfect storm of a different sort for your budget and your accounting department as upgrades for SQL Server are likely to be pricey. The improvements could dramatically improve workloads by lowering the time users spend waiting or increasing the throughput of queries. Those might negate the cost of any hardware and software costs involved since time is a valuable resource and saving time is worth something.

    The problem for many people is that if you aren’t writing good code, then you might not get the benefits you want from the upgrade. Certainly the performance improvements might be lost under poor query performance. Upgrade to take advantage of improvements if they are something you need, but please, learn to write better code, and ensure your developers are regularly looking for better ways to use your expensive SQL Server licenses by writing more efficient code.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and Libsyn.