February 10, 2016 at 8:39 am
We all knew this, of course, but here's another strong warning to test, test, and test some more before switching to using the 2014 CE: http://www.theregister.co.uk/2016/02/09/microsoft_sql_server_2014_bug/.
Another look at the incident, this time "from the horse's mouth" is here: https://blogs.msdn.microsoft.com/bharry/2016/02/06/a-bit-more-on-the-feb-3-and-4-incidents/.
Some of the comments are...interesting. After one comment notes the use of TOP 1 without an ORDER BY, another comment quickly pointed out that when using TOP 1, ORDER BY doesn't do anything. :hehe:
Cheers!
February 10, 2016 at 8:55 am
Interesting, thanks for posting this.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
February 10, 2016 at 9:03 am
The comments on the Register site show an incredible lack of understanding of SQL and its internals. But hey, this is the internet, you don't need to udnerstand something befeore you bash it. Right?
I also think that the Register exaggarates the issues and pulls it out of context. The MSDN blog is more balanced.
I fail to understand how this problem has not been detected in the QA environment. Unless I have to assume that they decided to flip the compat level switch without testing, which is a direct violation of the advice MS gives to its customers: https://msdn.microsoft.com/en-us/library/dn600374.aspx.
I also don't understand why, when the service went down shortly after deploying a change, the first reaction was not to immediately rollback the change. Because we all know that every major company always has a rollback script for any deployment, right? (And in this case, the script would have been reidiculously simple).
Just to make sure that we are all on the same page on TOP and ORDER BY - your last remark is cynical, right? You do know that there is a huge difference between TOP with or TOP without ORDER BY, right?
February 10, 2016 at 9:08 am
Hugo Kornelis (2/10/2016)
The comments on the Register site show an incredible lack of understanding of SQL and its internals. But hey, this is the internet, you don't need to udnerstand something befeore you bash it. Right?I also think that the Register exaggarates the issues and pulls it out of context. The MSDN blog is more balanced.
I fail to understand how this problem has not been detected in the QA environment. Unless I have to assume that they decided to flip the compat level switch without testing, which is a direct violation of the advice MS gives to its customers: https://msdn.microsoft.com/en-us/library/dn600374.aspx.
I also don't understand why, when the service went down shortly after deploying a change, the first reaction was not to immediately rollback the change. Because we all know that every major company always has a rollback script for any deployment, right? (And in this case, the script would have been reidiculously simple).
Just to make sure that we are all on the same page on TOP and ORDER BY - your last remark is cynical, right? You do know that there is a huge difference between TOP with or TOP without ORDER BY, right?
Yes, I was being cynical 🙂
The bit about testing was what struck me as well. The query is also suspiciously heavily hinted, but that may be ok, if they've determined through rigorous testing that that is what works best for that query; this issue makes me doubt that, though.
The huge increase in the memory grant and the drastic overestimate of rows would have been easy to catch in testing, so it seems they didn't do much, if any testing. That's the part that especially baffles me.
Cheers!
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply