Patching

Question

Post reply

Patching

sqlguru

SSC-Addicted

Points: 471
More actions
December 22, 2021 at 4:50 pm

#3966413

For the best practices who should be installing SQL Patches? I see in most of the organization it is installed by Windows team using SCCM and DBAs have no visibility. I would think that DBAs should be responsible since if ever the patch needs to be rollback or undo. Any thoughts or arguments?
January 4, 2022 at 9:58 am

This was removed by the editor as SPAM

Viewing 6 posts - 1 through 5 (of 5 total)

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

homebrew01 SSC Guru Points: 55548 More actions · Answer 1

Less important who does it, but all "stakeholders" should be aware of "what" , "when" , "why" ....

Generally DBA does it where I've worked.

This reply was modified 2 years, 11 months ago by homebrew01.

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 2

Where I work, the DBA patches the DBA software (SQL for example) and the IT team patches the OS.

So Windows updates are handled by IT and SQL patches are handled by the DBA. Now, this can result in 2 separate outages for updates if the DBA's schedule and IT's schedule don't mesh up nicely, but it works in our environment. We currently have all of the Windows OS patches handled automatically, which is good and bad. Means if I want to "mesh up" with an IT outage, I need to make sure that my updates complete prior to theirs or the system will reboot while I am using it.

Now as for "best practice" - I think that really falls onto an "it depends" situation. How large is each team? How much does your SCCM team know about SQL server and the patch being applied? What I mean is if they are installing a SQL Server CU that came out the day before, do they know if post-install work needs to be done such as rebuilding statistics? OR in the event that things go sideways with the update and the SQL instance fails to come online, do they know how to get it up and running again? If they need to have the DBA available on call to do post update steps or to be available for emergency troubleshooting, why pay 2 people to do the work when the DBA can (or at least should be able to) handle it on their own? Depending on what the patch is fixing or addressing, you may need to test some stuff after the patch is applied too. And if it does go completely sideways, who is better suited to roll things back?

Now, from an opposite standpoint, it MAY be that your SQL instance is running in a VM and the IT team manages the VM infrastructure. So if things go sideways and you need to restore from snapshot, you may still need an IT person on-call and available, so you MAY end up having 2 (or more) people ready to work no matter who does the update.

Now the only case where I wouldn't want the DBA doing the install is if the DBA doesn't know basic Windows troubleshooting and/or IT is not comfortable making the DBA an admin on the server hosting the SQL instance(s). If IT won't give me admin, I can't install the update, and therefore IT needs to do the install and likely the troubleshooting if the instance won't start after an update.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

Jeff Moden SSC Guru Points: 1004363 More actions · Answer 3

Where I work, the DBA doesn't do the updates. The infrastructure team does the Windows and SQL Server updates.

We wait a week after they come out and look for the public to do their thing.

We then do the Dev boxes and wait a week to see what breaks if anything in Dev.

We do staging after that and wait another week.

We finally do prod after that.

As careful as we are, there have been some updates that made a mess of 3rd party software (especially on Windows updates) and have had to do a rollback here an there. For the most part, though, any problems that have cropped up were found in Dev or Staging.

I'm always aware of the changes going on and have, at times, said "no" to a given change (normally NOT the whole update but have had some for SQL Server). We've also had "urgent" updates like this Log4J thing going on. Lordy. Really???

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Michael L John One Orange Chip Points: 27056 More actions · Answer 4

sqlguru wrote:

For the best practices who should be installing SQL Patches? I see in most of the organization it is installed by Windows team using SCCM and DBAs have no visibility. I would think that DBAs should be responsible since if ever the patch needs to be rollback or undo. Any thoughts or arguments?

They are installing SQL patches using SCCM? Regardless of the version of SQL, when these patches are run at the same time as OS patches. there always seems to be issues.

I have had various setups at places I have worked. Sometimes the DBA is responsible for whole server, sometimes the infrastructure team does the entire server.

Now, I let the infrastructure team know that a new patch is out there, and they add it to SCCM jobs that are separate from OS patches. I typically wait a few weeks after a new patch comes out. and like Jeff, it gets run on Dev one week, QA and Stage the next week, and finally production 2 weeks after that.

Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/