Question upgrading

  • itmasterw 60042

    SSCrazy

    Points: 2759

    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

     

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    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

  • itmasterw 60042

    SSCrazy

    Points: 2759

    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

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    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

  • itmasterw 60042

    SSCrazy

    Points: 2759

    okay thanks, I appreciate your advice here.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 717790

    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.

  • itmasterw 60042

    SSCrazy

    Points: 2759

    I agree, thank you, Steve.

     

  • Jeff Moden

    SSC Guru

    Points: 995976

    I always just ask management if they'd eat a 2 year old egg. πŸ˜€

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • DinoRS

    SSCrazy

    Points: 2640

    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!

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    Jeff Moden wrote:

    I always just ask management if they'd eat a 2 year old egg. πŸ˜€

    man , i'm stealing that quote

    MVDBA

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    DinoRS wrote:

    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

  • Grant Fritchey

    SSC Guru

    Points: 396384

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • DinoRS

    SSCrazy

    Points: 2640

    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.

  • Jo Pattyn

    SSC-Dedicated

    Points: 31373

    Things that are interesting in SQL 2019 are the accelerated database recovery and the new oracle driver for SSIS (preview)

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    DinoRS wrote:

    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 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply