April 26, 2018 at 9:26 am
Comments posted to this topic are about the item The Last Service Pack
April 26, 2018 at 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
April 26, 2018 at 5:12 pm
Piquet - Thursday, April 26, 2018 4:10 PMI'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 bugsPiquet
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
April 27, 2018 at 1:40 am
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!
April 27, 2018 at 6:56 am
what can you do? it's Microsoft doing DevOps / Agile etc.. we had also issues and needed to roll CU after CU ¯\_(?)_/¯
April 28, 2018 at 2:34 pm
Rod at work - Friday, April 27, 2018 10:38 AMThis 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
Change is inevitable... Change for the better is not.
April 28, 2018 at 7:29 pm
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