February 26, 2020 at 4:38 pm
Hi,
I see the post of going from 2012 - 2019 but we were wondering if we should go to 2017 or 2019.
Currently, we only have about 20 users and do not do anything with warehousing; of course, both could change down the road.
Someone said that they found it to be much less money. So I am wondering if there is a big advantage in going to 2019 or should we go to 2017.
Thank you
February 26, 2020 at 4:48 pm
going to 2019 will bring you longer term benefits... you won't have to upgrade from 2017, so your upgrade lifecycle is less expensive, but you will have to put some effort into testing which is usually put to a cost code on the budget
personally i'd go for 2019 and play with all the new toys.. you can always get the dev edition and see how much it breaks you code
MVDBA
February 26, 2020 at 5:05 pm
thanks for the reply, but I was looking for some key things that I could tell management that it is better to go to 2019 over 2017.
Thank you
February 26, 2020 at 5:25 pm
its pretty easy to google, but this might help
https://mindmajix.com/sql-server-2019#sql-server
personally I like the inline function optimisation and the mongo db integration into poly, but I think you need to work out what you need and then justify it that way. but putting 2017 (a 3 year old product) will have to be upgraded at some point.. that is your benefit
MVDBA
February 26, 2020 at 5:46 pm
okay thanks, I appreciate your advice here.
February 26, 2020 at 5:54 pm
The biggest things, from my view, in 2019 are the performance improvements in execution plans. correction, indexing, etc. have changed in 2017. There were a few things in 2017,but they were improved and more added in 2019. That, plus the additional time before you are out of support, mean that it doesn't make sense to go to 2017.
I don't think there is a cost difference, as I don't think you can buy 2017 now from many places. You would buy 2019 and then use downgrade rights to run the 2017 upgrade.
February 26, 2020 at 6:04 pm
I agree, thank you, Steve.
February 26, 2020 at 8:05 pm
I always just ask management if they'd eat a 2 year old egg. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2020 at 8:18 am
I still look at Memory-Optimized TempDB Tables with jealousy. I wish SQL Server 2019 was out there just a few months earlier and I would've argued for 2019 right away. As I'm about the only one on this world using Master Data Services I especially am looking forward to no more Silverlight but a HTML5 Webinterface!
February 27, 2020 at 8:41 am
I still look at Memory-Optimized TempDB Tables with jealousy. I wish SQL Server 2019 was out there just a few months earlier and I would've argued for 2019 right away. As I'm about the only one on this world using Master Data Services I especially am looking forward to no more Silverlight but a HTML5 Webinterface!
memory optimised tempdb - so many issues on the old memory optimised, i'm waiting to see who tries and fails on that one #dba coward
MVDBA
February 27, 2020 at 1:44 pm
Honestly, I don't know that I'd be knocking down the door today to move from 2017 to 2019. Mostly, 2017 is just working great. Mostly, 2019 is an awesome upgrade, but unless there's a particular piece of functionality that your business can put to work, I'm not sure I'd charge down the path for an upgrade.
However, that said, the one piece of functionality that might make me change this Accelerated Recovery. That might do it. It's a hill I'd be willing to die on. It could radically change your Recovery Time Objectives, making your systems much more resilient in the event of data loss, disaster recovery, all the rest.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 27, 2020 at 1:47 pm
If I get a chance to, I'll happily be the first one to make it work in production. Same as I got Memory Usage of Memory Optimized Tables under control without Resource Governor, I'll happily go see if and how much I can benefit from this one.
On a sidenote: Using In-Memory Tables I was able to reduce the nightly load time from 9 hours to one even tho we have no control over the underlying infrastructure (which essentially is bad and slow), happy to be that DBA / Dev coward just without Twitter hashtags.
February 27, 2020 at 3:03 pm
Things that are interesting in SQL 2019 are the accelerated database recovery and the new oracle driver for SSIS (preview)
February 27, 2020 at 3:18 pm
If I get a chance to, I'll happily be the first one to make it work in production. Same as I got Memory Usage of Memory Optimized Tables under control without Resource Governor, I'll happily go see if and how much I can benefit from this one.
On a sidenote: Using In-Memory Tables I was able to reduce the nightly load time from 9 hours to one even tho we have no control over the underlying infrastructure (which essentially is bad and slow), happy to be that DBA / Dev coward just without Twitter hashtags.
Dino that's fighting talk about the hash tags 🙂
the one function of 2019 I think we will use is the integration of MongoDB into Polly - but I am not tempted by Tempdb in memory #stillAcoward
MVDBA
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply