Let’s start with CU6. This update for 2014 SP1 came out recently and had a bug: it could cause NOLOCK issues on your server. Not a good thing. That CU has been removed and this new one issued. But they didn’t change the number: it’s still CU6. They changed the KB article number behind the update, but they kept the same update number. This could definitely cause some confusion. Steve Jones, one of the founders of SQL Server Central, wrote about this on his blog, expressing an interesting opinion. He thinks that, while the prompt and frequent release of CUs is a good thing, that the rapid release cycle could cause some problems with shops that have narrow maintenance windows. I think that’s a good point. I’ve been fortunate in that every shop that I’ve worked in had strictly an 8-5 operation timeframe, so I never had any problems applying patches, but I can see the issue. Steve also posits that Microsoft might go away from Service Packs entirely and issue all bug fixes through Cumulative Updates. I’m not sure I agree with that, but I can’t point to anything solid behind my belief, so we’ll wait and see.
Regardless of whether or not you’ve already installed CU6, you need to re-install it.
Perhaps the best way to keep track of Service Packs and Cumulative Updates for any currently supported version of SQL Server is through a web site that Brent Ozar created, SQL Server Updates. You can subscribe and whenever a new CU or SP appears, you’ll get an email. Pretty nifty, eh?
Speaking of Brent, a blog post today had some news that I’m not too keen on. As we know, SQL Server 2016 launched this week. A study of the EULA that you must agree to before installing produced a couple interesting bits of tid. First, SQL Server, if it’s connected to the internet, auto-updates. If a patch is available, it will download and apply it. I am not at all keen on this as there are far too many stories over the years of an SP or CU breaking an installation. And what happens if said patch auto-install requires a service or server restart? Does it do it regardless of usage, or what? I do not know, but I expect we’ll be finding out about this soon.
The second part of Brent’s post was that SQL Server 2016, by default, phones home with telemetry reports. THIS IS BUILT-IN, AND YOU CAN’T TURN IT OFF. Well, you can turn it off if you’re running an Enterprise edition via a registry key change. And you can probably block said transmissions via firewall rules. Here’s the problem: what if your network contains HIPAA information? Or student information? Or credit cards? How do you know what is being sent to Microsoft and what is being done with it. You can’t. For that matter, it’s possible that the information is not going to Microsoft and that it’s going to a third party for aggregation and analysis.
There is a Connect item, actually created by Brent, to give DBAs the ability to turn off this automatic telemetry transmission. As of the time of me writing this, there were two comments on the Connect page describing installations that, due to the information that they store and process, absolutely would not upgrade to 2016 until this is removed.
As it happens, I’ll be setting up a new server with 2016 Developer’s Edition in the near future, and I’ll be keeping a close eye on my firewall log and blocking ports left and right. For that matter, that particular computer doesn’t need internet access, so I might just block it from accessing the outside world at the router level.