Tag: upgrades

I heard from a member of the community that’s still on SQL Server 2005 recently. Yes, 2005. That’s an old, unsupported version, but they’ve got some Access/VBA apps that work well and aren’t worth investing a lot of development effort in. The person noted that they could only upgrade to 2008 R2 without rewriting code, and they didn’t want to move from one unsupported version to another.

I suspect a few of you are in this situation, though it seems many people I know that still run 2005 (or 2000), also have newer versions of SQL Server running. As there is the need, or opportunity, to replace and upgrade instances, they do so.

In this case, it seems there’s not good case to upgrade. A change to newer code would be expensive, but also licensing costs have dramatically risen. If the existing hardware were an older 4CPU (licensed), perhaps dual code x 8GB RAM system from, let’s say, 2008 ish hardware, that’s a quad core machine. While you might be able to run on fewer cores with today’s processors, you’d still be looking at a quad core, single CPU as a minimum for licensing and hardware.

There’s also the decision of upgrading to 2014 with new code. That could be a significant effort, with resources spent here instead of on new development. Is that worth it? I think it’s hard to decide without knowing more.

Is it worth it to upgrade to 2008 R2? I’m not sure. While you get some enhancements, you’re still moving to a version that will go out of mainstream support in a year or two. I’d say this isn’t worth the cost.

Ultimately I think Microsoft is shooting themselves in the foot a bit with the minimum core requirements and larger licensing costs, without giving customers flexibility. I think Microsoft would be better served by letting customers license the scale they need.

Steve Jones

The Voice of the DBA Podcast

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

We have a name for the next version of SQL Server: SQL Server 2016. I suspect the internal build may be v14, which I guess makes sense if you’re superstitious about the number 13, or you think your customers are. There are plenty of v13s out there for various other software packages, so I’m not sure if this is an issue, but we’ll see when we get a public CTP for the next version of SQL Server.

vNext has been the way to refer to the next version of Microsoft products before a decision is announced about the official name. This convention seems to have taken over from code names, which makes sense, but it certainly is less fun than hearing Denali, Yukon, or some of the names that have been used for SQL Server. 

Perhaps this is a sign of maturity within Microsoft? It certainly could be as releasing a new version of SQL Server every two years doesn’t happen without some discipline and rigorous engineering effort. Despite the issues with SQL Server 2014 SP1, I do think Microsoft has done a nice job taking a formal approach to software engineering with SQL Server.

I am a bit more interested in SQL Server 2016 than I was in SQL Server 2014. Perhaps that’s just the fact that some significant changes might take longer than two years to implement and a number of them are coming in SQL Server 2016. I certainly looked forward to SQL Server 2008 and SQL Server 2012 more than the “R2” and 2014 releases. It has seemed that every other release has more significant enhancements and includes more reasons for me to consider upgrading. I think SQL Server 2016 is one of those releases.

The datasheet shows a number of features that I Think make this a compelling release. I worry about security and the Always Encrypted idea seems very interesting. We’ll see how it looks once we get details. I like the improvements to AlwaysOn as well as the changes to include JSON and R support into the database engine. Row Level Security is in Azure now, but I think that’s important in the boxed product, and, of course, the Query Store is something I’ve been looking forward to for years. If you don’t know about that, read about it now. I was hoping to link to Conor Cunningham’s SQL Bits session, but I’m guessing recording wasn’t allowed.

There’s more coming, including the “Stretch to Azure” feature, which I’m not sure about. I’d feel better about “copy to Azure”, but perhaps I can keep local filegroup backups of this data, so that might make sense. I’m sure many of you won’t like some features, but this does seem like a compelling release. Depending on how pricing and licensing might change.

Steve Jones

The Voice of the DBA Podcast

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

There was a post from the SQL Server Data Platform Advisor the other day that noted it’s been almost 10 years since SQL Server 2005 was released and it’s time to upgrade. At least, if you want to remain in support. Microsoft Support notes that support ends on Apr 12, 2016, which is just under a year away. While that might seem like a long time, it can take months to get an upgrade approved, planned, and executed, so if you think you’ll want to upgrade before support ends, you definitely should start planning.

However, do you need to upgrade?

That’s an interesting question. I would assume that if you have SQL Server 2005 in your environment, it’s been running since sometime before the end of 2009. It’s possible you installed 2005 after SQL Server 2008 was released, using the downgrade rights you have. I expect that you might have done that for a year, but I’d hope that if you were installing new instances after 2010, that you were using 2008 or 2008 R2.

Given that assumption, I’m guessing that you’re relatively pleased with how SQL Server 2005 has been performing. At least I’d think you are. If you’re not, then why haven’t you upgraded? If it’s budget, then does support ending really make a difference? If whoever approves purchases has been satisfied with performance, why upgrade now? If your database backs a third party application, will you have to upgrade that code as well? If so, another reason it might not be worth making a change.

We haven’t really seen patches for SQL Server 2005 in a long time. There have been two hotfixes and one security update since the last Cumulative Update, and the last one was in 2012. While I do think it’s possible that more security bugs might be found, the likelihood is low. Chances are that if you’ve been secure this long, you’ll still be secure for a few more years.

If you are continuing to develop your code, however, there are lots of improvements in later versions of SQL Server that you might take advantage of. T-SQL has continued to grow and progress, with new features. Replication has improved, as have some of the manageability of the servers. Certainly security and encryption have advanced, so those could be reasons to consider moving to a more current version. The wealth of information available for tuning your system, as well as more efficient code and a better query optimizer might lead you to consider both a hardware and software upgrade.

While there are some compelling reasons to upgrade with greatly improved performance and many more features that can help improve development, if you have systems that are working then is it really worth the licensing cost? Especially now that SQL Server is licensed by the core and not socket. Working is a feature, and one that I do think is worth considering as part of your decision.

Steve Jones

The Voice of the DBA Podcast

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

When I’m talking to people working with SQL Server, many of them are quite pleased with the platform. It solves their issues and problems. While they always wants changes and improvements, not to mention bug fixes, overall most people seem happy with their particular version. However, there’s no shortage of things that are slightly broken in SQL Server, and while I appreciate the Cumulative Updates every other month, I’d like to see even more work done fixing code.

The development of SQL Server has accelerated in the last decade. After the five year span from SQL Server 2000 to 2005, we’ve seen new versions coming just over every 24 months, and I expect that to continue in the future. This rapid release cycle means that many of us end up supporting 3, 4, or more versions of the platform at any one time.

We often install the latest version for new instances, often because that’s the only version we can buy at any time. However we don’t seem to upgrade older instances quickly. This week I’m wondering why.

What are the reasons that prevent you from migrating those 2005/2008/2012 instances to 2014?

Are there technical reasons you don’t upgrade? Is it cost-related? Or is there no compelling reason to adopt the newest features and enhancements to the platform? I suspect a combination of these reasons for many of you, though I also feel the platform is very mature, and has been for many versions. The applications I run, primarily SQLServerCentral, don’t really benefit from any of the features in later versions.

Let us know this week, and I’m especially interested in knowing if there are technical reasons any of you can’t upgrade.

Steve Jones

The Voice of the DBA Podcast

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

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.