The Case for Patching

  • Comments posted to this topic are about the item The Case for Patching

  • Such as nice article very informative knowledge

  • Thanks for the article Steve.

    While we know patching is critically important, it's still hard to get it completed.

    Some is resistance from DBA's, some from Dev's and some from "we can't reboot servers because clients might be inconvenienced".  So less of a technical issue and more politics.

    I've worked with DBA's who dragged their feet on patching every...single...month and couldn't get IT management to support me on patching. So again, less technical and more about politics.

     

     

     

  • mikep7 wrote:

    Thanks for the article Steve.

    ...

    I've worked with DBA's who dragged their feet on patching every...single...month and couldn't get IT management to support me on patching. So again, less technical and more about politics.

    I've seen this, and I've worked as a DBA to be better. A good friend did the Windows patching the early 2000s and I apprecited how often he kept things up to date.

    I think this is a little politics to get it done, but it's more that management doesn't see a value and they just don't want to deal with or be concerned about upset clients. DBAs get scared about potential problems, or they just don't want to work after hours.

    To me, I'd just keep gathering evidence when a lack of patching causes an issue or a crisis. I'd also point to the old adage, let's not change multiple things at once, so don't apply new code to the db and patch the server. That's kind of silly.

  • It has been some hard work to get every one on the same track when it comes to patching the systems. Lots of complaints and " we must have this system running, what happens when it reboots ?? ....

    But now we apply patches every month using WSUS.  Test environment one week before prod so that developers and app. management can check for problems.

  • Lately there was some visibility because of an Apple OS bug. We've found a rather annoying bug that allows remote takeover, patch asap

  • The case against patching (of SQL Server CUs) is that all databases are updated with a single thread during the CU update process, dusring which the SQL Server is unavailable. When you have a large number of databases (we have SQL Server instances with up to 10,000 databases) we have experienced up to 5 hours of complete downtime.

  • SebastianT wrote:

    The case against patching (of SQL Server CUs) is that all databases are updated with a single thread during the CU update process, during which the SQL Server is unavailable. When you have a large number of databases (we have SQL Server instances with up to 10,000 databases) we have experienced up to 5 hours of complete downtime.

    That's unlikely to get more efficient, but I would think with that many you have AGs or some HA tech in place. Ought to be able to failover, patch, fail back.

  • We do fail overs when patching. The only gotcha is to make sure there are no "Jobs" running at the time that could be interrupted.

    If there are tons of servers to patch I recall hearing that this could be automated with Powershell.

    ----------------------------------------------------

  • A couple years back I was interviewing for a DBA position with many companies.  I was shocked that almost all of them barely applied Windows patches or hadn't in over a year.  It is one of the first questions I ask in the interview process.

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply