1

I am aware of Brent's post Why Nobody Ever Patches Their SQL Servers in this regard.....and with one of my friend, please assume one such scenario, where nearly 100 SQL Servers are never patched. Assume that no bugs or performance issues have ever been reported by any user. So, is there a cool way for my friend to identify across all the servers - where he is unaware - and few of the servers may already be hitting some bugs? In other words, how to pro-actively find the bugs across 100 SQL Servers?

One plan is to read release notes of those bugs where bug could be identified using a server trigger on occurrence basis (may be) .... capture that in local tables....SSIS those at a central location.

But, does this plan seem worth?

Special interest on those bugs where some impact on data by any chance. (FYI, DBCC CheckDB with purity runs error-less). Or some possible loss to business.

And finally assuming that, indeed, some bugs detected in some SQL Servers - so, how and why to treat them as "threat" when no issue reported by users ever from many years?

Improve this question
9
  • 1
    Yes, your idea is interesting, i.e. finding out the bugs in unpatched SQL instances. But why bother wasting such time, just patch them to the latest patches available, period. Your time can be more valuable in other areas.
    – jyao
    Commented Apr 17, 2018 at 17:18
  • 1
    Please assume that the default go-ahead for SQL patching is denied just because the patches are available. Also denied because no issues reported by any user. The DBA ghost in my friend is still fired on how to convince for SQL patching. Hence this thought of proactive search for bugs.
    – Channdeep Singh
    Commented Apr 17, 2018 at 17:21
  • 2
    What about vulnerabilities? Aside from bugs which would cause unexpected operations, there is the security aspect to consider. Also, regarding your comment when no issue reported by users ever from many years, I wouldn't use this as a basis for not patching. Just because a user hasn't reported a data error, or calculation error, or whatever doesn't mean it isn't happening. It also doesn't mean they aren't simply ignoring it because it always happens.
    – S3S
    Commented Apr 17, 2018 at 17:28
  • 6
    Wait - what do you mean Brent's post on this? I'm a huge, huge fan of patching SQL Server.
    – Brent Ozar
    Commented Apr 17, 2018 at 17:37
  • 1
    Just because users haven't reported issues doesn't mean that they haven't been affected by them. Nor does it mean that tomorrow, a user won't be affected by them.
    – alroc
    Commented Apr 17, 2018 at 19:08

4 Answers 4

Reset to default
13

I assume you're talking about me, and I'm not sure what post you mean, but here is my thought:

Patch your SQL Servers regularly.

I'm such a huge fan of patches that I wanted to make it easier for people to find the most current updates for SQL Server, so I built SQLServerUpdates.com.

If you ever want justification for why you should be patching, just go back through the list of hotfixes in each cumulative update that you've skipped. You'll find bugs that deliver incorrect query results, and that's usually all management needs to hear in terms of why we need to patch.

Here are just a few fixed SQL Server 2017 bugs for incorrect query results - not an old, dusty version of SQL Server, but the brand new one they just released:

And all that was only the first cumulative update. Want your query results to be accurate? Get your patching on.

Improve this answer
3
  • Hiii sir, Yes, I meant you, and your below post: brentozar.com/archive/2015/08/… Its a big thing for me to have a comment from you. Woww ! I meant that all the bullet points listed in your post are after the decision of patching has been made. They are sort of advance preparation. But struggling to convince for regular SQL patching. When talk for bugs, I get an answer that no inaccurate results reported any user ever. And a message that patching can indeed introduce errors and increase huge unnecessary work and rollbacks later.
    – Channdeep Singh
    Commented Apr 17, 2018 at 17:56
  • 3
    Hahaha, yeah. That's about why people don't patch - but they SHOULD. I understand why they don't, but they need to, heh.
    – Brent Ozar
    Commented Apr 17, 2018 at 18:05
  • I have made a plan. Regarding the vulnerabilities, I found and will try the "SQL Vulnerability Assessment" in SSMS 17.4 for SQL2012+. Regarding the bug fixes, I will go through the release notes of quite a few ServicePacks; and try to somehow capture and showcase the ones that are already hitting. Regarding the performance, this will be quite a journey, but I believe that doing capacity plan for all SQL Servers pre and post patching, and show the improved perf counter values as proof in some TEST environment. What say?
    – Channdeep Singh
    Commented Apr 17, 2018 at 18:59
4

All software has bugs. Period.

I've heard it all over the years as to why people don't patch, but you are just going to cause heartache at some point. To be mission critical, maintain performance, availability, and security, and so on, you need to install updates. No one is saying to patch day one with most things (I would say Meltdown/Spectre are exceptions).

The longer you wait to patch, the more change you take, it's higher risk that something could break. Even if you don't apply every patch in production, you should be testing these more often in non-production environments.

You should patch your OSes, too. It's not just SQL Server.

Pay now, or pay later. It's much more painful - and costly - to pay later.

Improve this answer
3

The strategy I take with any client is that if I'm going to be responsible for their data (ensuring it's availability, integrity, security, etc.) then not patching is not an option. It's no different from OS patching. I bet you'd be hard pressed to find a business that told its sysadmins that they won't allow them to patch thier server OS's. It's the same table stakes, and I'd argue that they're even higher for the data, regardless of whether they've encountered that specific bug or specific performance issue or specific security threat mitigated by a given patch.

Improve this answer
1
  • Yes Yuri, I totally agree with your thoughts. However, arguments have failed; and now seniors colleagues could be convinced with data proof hopefully. Hence, finally this plan now as typed in the comments above to the answer shared by Brent Ozar. Many thanks.
    – Channdeep Singh
    Commented Apr 17, 2018 at 19:14
1

Every SQL server is subject to Meltdown and Spectre exploit critical vulnerabilities

It allows a rogue process to read all memory, even when it is not authorized to do so

The SQL patch has only been available since January 2018

The only solution for your shop is to apply all the current Service Packs and the last Security Patch for all their server versions.

Related: Do I need to install SQL Server service packs to continue receiving security patches

Improve this answer
2
  • Thanks James. Yes, this vulnerability point will be taken. But, most probably, will first be asked to prove its use case. Is there a way to capture this in advance?
    – Channdeep Singh
    Commented Apr 17, 2018 at 18:43
  • 1
    @ChanndeepSingh patching after you've been impacted by a known vulnerability is closing the barn door after the horse has bolted. There is no excuse for not keeping your software patched and up to date.
    – alroc
    Commented Apr 17, 2018 at 19:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.