Yesterday, Microsoft announced availability of Service Pack 1, saying:
As part of our continued commitment to software excellence for our customers, this upgrade is available to all customers with existing SQL Server 2014 deployments via the download links below.
Yeah, about that commitment to software excellence.
This morning, the download is gone:
Notice: The SQL SSIS team has found an issue with SP1 installation if SSIS catalog is present in the SQL Server instance.They are currently investigating this issue including possible workarounds and fixes.
Oof – the term “possible workarounds and fixes” doesn’t sound good for those who jumped in and applied the patch. A commenter on the MS Data Platform Insider blog reported that it hosed the master database broke the instance in a way suspiciously similar to a similar bug in SQL Server 2012 SP2.
(And jeez, what is it with service packs lately? Remember the SQL 2012 SP1 100% CPU issue? I’m starting to think you’re safer with cumulative updates than with service packs.)
Remember, kids, don’t rush into patching. If your servers are mission critical, test in your staging environment first – staging is the DBA’s development. (No, your development environment isn’t staging – because your developers make their living in the dev environment, and if you broke that with SP1 yesterday, you’ll be slaving away today to get your dev instance back up and running.)
Update: the fix is in. If you applied SP1, follow the instructions in this StackExchange post.
24 Comments. Leave new
i just don’t get it, do they test service packs before releasing them? you can’t have something like this in less than 1 day after releasing it…
Really not a good day for the SQL Server team…. Service Packs, and especially delivering service pack 1, may not be very sexy but it’s important for the community…
Is the SQL Server code base such a beast that the smaller and frequent updates is not practical?
I know it gets old applying an update or two a week. But if smaller incremental updates can minimize the disastrous, up all night recovering from hinky service pack sessions, I’d be for it.
Requests for help are already coming in @serverfault http://serverfault.com/questions/683174/sql-server-2014-sp1-installation-failure-bug-in-ssis-hotfix-install-sql.
Master databases are overrated….I mean do you really need one?
Experienced just yesterday the mentioned 2012 SP2 goosing the master even though l had many times success with it in the past work that one out?
Not come across the 2012 SP1 100% CPU max’d out issue yet but most servers in our supported estates are patch up almost straight away beyond it now up to 2012 SP2 CU5 success.
its a fingers crossed experience some times ……. love SQL 😉
It used to be for any SQL Server release, “wait until SP1”. Now for any service pack, I’m in the pattern of “wait for CU1”. Initially, it’s because the service pack would not contain some of the recent RTM updates and I’d wait for them to get rolled in. Now you have to apparently wait for them to fix the bugs.
To be fair, this problem doesn’t “hose” the master database. The error message that appears might not have the best wording, but really what happened is – because of the untested SSISDB script – the script level upgrade failed, which just means @@VERSION hasn’t changed. So far I haven’t heard of a single case of master actually being damaged, though you may have to jump through hoops (as indicated in the ServerFault thread mentioned in a comment above) to get the instance to start up again.
Aaron – bad news, man: https://twitter.com/NikoNeugebauer/status/588499442556227584
You saw his follow-up, right? Master wasn’t damaged after all.
> Delete & Restore SSISDB was the solution for me.
Sorry, hit Enter too soon. He had to restore SSISDB, and that may be a serious problem for some who don’t have an appropriate backup, but master wasn’t hosed.
OK, great! Thanks for the heads-up, will amend the post for now.
One comment: 6.5.252
Gawd I feel old school for even remembering that debacle.
Thanks for the info. I am getting ready to deploy SQL 2014 EE in a dev environment and I was going to got right to SP1. I hold off until the dust settle.
Honestly, what is with this stuff, are the people their testing with just burnt out or is this a result of the people that make the decisions passing the buck to some other underling who is doing the work and them just rubber stamping whatever they get…. sheesh …. I know I expect better from MS so they need to get their acts together.
Scott – that’s a tough question. I know when Satya Nadella took over, he announced cutbacks in QA, but I can’t really pin the blame on that. After all, we had the similar challenges with SQL 2012 SP1. All I can chalk it up to is that software development is hard – I know it’s tough as hell, I’ve been there – but still…
The 2012 SSISDB bug I kind of get, they did warn about patches and updates with AlwaysOn and SSISDB (first Google entry on search term: ssisdb availability group)
http://blogs.msdn.com/b/mattm/archive/2012/09/19/ssis-with-alwayson.aspx
So from what I read this 2014 version is irrespective of the AlwaysOn situation. That’s pretty poor not putting in a use statement. With the ramp up in releases every two years, it is a bit worrying. Are the customers taking more of a testing role?
Any updates now that the patch has been re-released? Anyone having any issues? I installed it without any issues (yet).
Just an update.. no issues with SP1..
So I see that MS has re-released and Chad has installed and not run into any undocumented features 🙂
anyone else tried the install or heard of any issues?
while i like these warnings, they need to be deleted or updated up top after its fixed.
Alex – make sure to read the whole post. It was updated. Enjoy!
I faced issues after migrating databases from SQL 2008 to SQL2014 SP1 with heavy Performance issue. Done all rebuild index, DBCC, UPdate stats all.. not sure.. and also the new server is VM. I am planing to move SQL 2014 SP2.. any suggestion?
Suresh, this I doubt has much to do with Brent’s post. The engine optimiser works differently in 2014 than it has done in previous versions. Trace flag 4199 that is enabled by default in 2016 may help with some of the changes MS have made since RTM (i.e. activates some of the updates rather than leaving them laying dormant). Ultimately some of your queries may however need re-writing.