SQL Upgrades

Fear

Today’s another T-SQL Tuesday, thanks to Steve Jones. This month he’s asked us to talk about SQL upgrades.

I thought I’d write about a SQL Upgrade that wasn’t.

As a DBA I’ve worked with SQL Server since 4.21a. Yes. I’m that old. And a common experience I’ve had, which I suspect I share with many DBAs, is that every company I’ve worked with, either as an employee, or as a consultant has been reluctant to upgrade.

And often it’s understandable. Depending on their licensing situation and finances, an upgrade can be costly, especially for a smaller company. So companies often soldier on with older versions. In fact, just the other day on Twitter, I saw a post from someone asking about tuning queries on SQL 2020. In any event, especially as a consultant, I’m not alone in seeing resistance to upgrades.

But one client really stands out. I started working with them about a decade ago. They were running SQL 2005. Now, if you do the math, you’ll realize that by this time SQL Server 2008 and SQL 2012 had come out.

Technically I was brought in for a separate project, but when they became aware of my skills, they asked me to help tune their current database. There were some easy lifts (such as removing a duplicate index on a particular table that did nothing to help select performance, but obviously hurt insert performance). But by far one of their worst performing procedures was one that was handed an XML string which it then had to parse. I made several recommendations but realized that as long as they were depending on this stored procedure to parse the XML and were using SQL 2005, this would be a huge bottleneck. There was a pretty common and known issue with the way that SQL 2005 parsed XML.

The simple and obvious upgrade was to upgrade, ideally to SQL 2012. The answer was a firm “no”. It wasn’t even the cost, it was fear. It seems they, like many folks who had done the upgrade from SQL 2000 to SQL 2005 had hit several performance issues due to changes in the query optimizer and were afraid that they’d have as bad or worse issues upgrading to SQL 2008 or SQL 2012. They were far more comfortable with the devil they knew than the devil they didn’t.

Now, I can fully appreciate this, but it was frustrating. It was more frustrating because their business was fairly seasonal in nature, which meant that they could have done the upgrade soon after their busy season and had 8-9 months to debug performance issues. They would have also gained other benefits from the upgrade.

I’d love to say I finally had shown them enough proof of the advantages, had shown them how low the risk would be, and how to mitigate such risks. Alas, I didn’t. They decided (and to be fair there were other reasons completely unrelated to their SQL Server concerns) to migrate to a full LAMP stack. SQL Server was out, MySQL was in. Of course they had other issues there, but those weren’t my problem.

Upgrading SQL Server Today

I knew then, and still know now, that the upgrade would have been far less of an issue than they feared. But, I couldn’t and still can’t completely dismiss their fears. They were far from the only company that had been somewhat burned by the SQL 2000 to 20005 upgrades. I’ve heard of other companies that resisted upgrades during that era for similar reasons .I still sometimes hear echoes of such fears. And let’s be honest, often a database server is absolutely essential to the core of a company. Unlike front end code that might be easily rolled back, often SQL upgrades are very hard to roll back. (In reality it’s not as bad as some think, but it’s often non-trivial also.)

I will give Microsoft credit for listening. Since then, I know they’ve taken a lot of steps to mitigate such fears and have made backwards functionality a far higher priority than they used to. Other than licensing costs, honestly, at this point, I think companies should be on a regular update cycle. There’s almost always performance benefits and these days, the drawbacks are pretty minimal. And honestly, if you’re on Azure, you’re being upgraded without knowing it.

My advice, don’t fear the upgrade, anymore.

1 thought on “SQL Upgrades

  1. Pingback: T-SQL Tuesday #147 Wrap-Up | Voice of the DBA

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s