The Last Service Pack

  • Comments posted to this topic are about the item The Last Service Pack

  • I'd like to share your optimism for the CU release model, however so far we have had a couple of not so good experiences in this space with SQL Server 2017, that not only makes me wonder whether this is a good model, but also makes me wonder how much Microsoft have cut down on testing the releases (compared to Service Packs) as part of this shift.

    We've had to roll-back SQL 2017 Cumulative Updates back to RTM due to breaking changes causing SSIS package failures (cube process task).

    We also had recent similar issues with the "SSDT 2017 for VS 2015" installation (the dev tools for SQL 2017). This is a "stub installer" that downloads the latest binaries at install time. After downloading and successfully testing SSDT on one of our developer workstations we then rolled out SSDT 2017 to all other DEV workstations to find that not only had the binaries used by the installer stub changed since testing, but also that the project's XML file format appears to have changed and is not compatible between these 2 downloads!

    If this strategy of "no more service packs" and monthly cumulative updates is to be successful, Microsoft need to:
    - ensure that they keep on top of pre-release testing
    - increase the amount of testing that is conducted (not cut back on it!)
    - have a solid channel for customers/users to provide feedback and bug reports through (like the MS-Connect channel that was recently shut down and replaced with a blog)
    - be able to respond swiftly in resolving reported issues and bugs

    Piquet

  • Piquet - Thursday, April 26, 2018 4:10 PM

    I'd like to share your optimism for the CU release model, however so far we have had a couple of not so good experiences in this space with SQL Server 2017, that not only makes me wonder whether this is a good model, but also makes me wonder how much Microsoft have cut down on testing the releases (compared to Service Packs) as part of this shift.

    We've had to roll-back SQL 2017 Cumulative Updates back to RTM due to breaking changes causing SSIS package failures (cube process task).

    We also had recent similar issues with the "SSDT 2017 for VS 2015" installation (the dev tools for SQL 2017). This is a "stub installer" that downloads the latest binaries at install time. After downloading and successfully testing SSDT on one of our developer workstations we then rolled out SSDT 2017 to all other DEV workstations to find that not only had the binaries used by the installer stub changed since testing, but also that the project's XML file format appears to have changed and is not compatible between these 2 downloads!

    If this strategy of "no more service packs" and monthly cumulative updates is to be successful, Microsoft need to:
    - ensure that they keep on top of pre-release testing
    - increase the amount of testing that is conducted (not cut back on it!)
    - have a solid channel for customers/users to provide feedback and bug reports through (like the MS-Connect channel that was recently shut down and replaced with a blog)
    - be able to respond swiftly in resolving reported issues and bugs

    Piquet

    Great points and I totally agree. I have a lot of concerns along the same lines as well as a few others.
    Plenty of places won't/can't do monthly updates due to their own testing needs, SLAs for uptime, etc. And the testing by the consumer is needed more and more as the problems and issues with the continual upgrades cause way too problems as you've said. MS has been struggling with stable builds of SSDT, SSMS - you pick what you want to be broken sometimes in deciding what versions you use. I have no desire to play that game with the database engine. 
    And too many of the updates do require restarts/reboots even when they say "no restart required". Having to deal with half baked new features and unplanned outages counted against uptime SLAs, etc. seems to be becoming the norm. And features are now more important than stability.

    Sue

  • If you're looking to upgrade to SQL 2016 or SQL 2017 and you use reporting services with custom authentication - then FYI it will fail.
    You will have to find a way to rewrite your custom authentication DLL, see my MS forum post - I'm not the only one, https://social.msdn.microsoft.com/Forums/sqlserver/en-US/f474ba23-7e8d-4c6b-ad41-b2327956226b/sql-2016-reporting-services-custom-security-how-to-access-name-of-item-being-accessed?forum=sqlreportingservices

    Also you can only install 1 instance of SSRS 2017 per machine - uber-sigh. MS give with one hand (SQL 2016 SP1) but take away with the other!

  • what can you do? it's Microsoft doing DevOps / Agile etc..  we had also issues and needed to roll CU after CU ¯\_(?)_/¯

  • This change in how Microsoft is pushing out updates, using CU's instead of SP's, is going to through some people off, I think. I've known enough DBA's what only seem to apply SP's and ignore the CU's.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work - Friday, April 27, 2018 10:38 AM

    This change in how Microsoft is pushing out updates, using CU's instead of SP's, is going to through some people off, I think. I've known enough DBA's what only seem to apply SP's and ignore the CU's.

    The reason for that is MS used to recommend against installing CUs unless there was a particular issue that absolutely needed to be fixed.

    --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.

    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)

  • Jeff is correct, and this is one reason I recommended against them. They weren't as thoroughly tested, and there was legal wording added to the documents noting that if you didn't experience the issue, you ought to wait for the next SP.

    The CUs now receive extensive testing. I'm not sure SPs get more these days, especially the last few. That doesn't mean they're perfect or they don't need more tests, but I think they are as heavily examined as any patches the SQL Server team builds.

Viewing 8 posts - 1 through 7 (of 7 total)

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