June 15, 2017 at 3:15 pm
We are currently using SQL server 2014 and SQL server 2012.
I am planning to upgrade them in Oct to SQL server 2016.
But I know 2017 version is on the way. Shall I wait to upgrade to SQL server 2017?
I don't see we are going to use the new features in SQL 2017, like Python, graph database etc.
And our developers are not always available for testing when doing upgrade. They are busy with other things.
so try to do less upgrade as possible. But it seems now each year SQL server has a version.
Thanks
June 20, 2017 at 11:36 am
That is a tough situation - and not unique, especially with the pace of the versions as you said. At this rate, I don't see where a lot of companies can realistically upgrade every year or two so I would think the value of being on the latest version isn't as significant as it used to be. I don't think there is any right answer to your question - it really depends on you, the company, the environment you are in to determine what makes the most sense while considering the best interest of the company.
Sue
June 20, 2017 at 1:47 pm
My opinion, if the upgrade to 2017 offers no features that you require, I'd stick with 2016.
The main reason for this - it has been out for a while and most of the bugs have been fixed.
Jumping onto the latest and greatest sometimes introduces new bugs that you were not expecting and that can affect the way that your things are currently working.
If you do not see the benefit of using 2017, then I would stick with 2016. It has been tested a lot more and has service packs out for it. But even going to 2016 you will NEED to test. If your developers are not willing to test, that is a big red flag! You should go to their supervisor and your supervisor and let them both know the risks of doing untested upgrades. Hypothetically, lets say they are using SQL to do generate hash values for some column or a result. Then lets say they are explicitly using the MD2, MD4, MD5, SHA, or SHA1 hash algorithms. When you upgrade to 2016, those functions will break unless you have compatability level set lower than 130. Breaking changes in 2016 - https://docs.microsoft.com/en-us/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2016
If they refuse to test it and things break, it is possible that they will blame you. You are the DBA (Default Blame Acceptor).
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
June 20, 2017 at 2:48 pm
I haven't recommended keeping up to the latest version since SQL 2012, 2 year release cycles are tough to keep up with. 18 month is going to be near-impossible.
Start testing for the app on the SQL Server 2017 CTP. You need to test, there's the cardinality estimator changes (from SQL 2014) at the minimum that can break things. Keep an eye on 2017, see if there's anything that will be useful. Adaptive query plans, automatic plan forcing, graph support, etc. If there are, you can upgrade to 17, if not, upgrade to 16, it the app works on 17, it should work on 16 as well.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 20, 2017 at 3:45 pm
Testing, in my opinion, is an absolute necessity. It's not optional. There's the stuff Gail pointed out, plus anything you don't know about.
If people won't test (no matter the reason) then it isn't the right time to upgrade.
I didn't stay current with 2005, 2008 or 2012. I'll never be able to stay current with the current pace of new releases.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply