June 22, 2011 at 5:26 pm
I cannot recall ever using the windows automatic update to patch critical servers. It is apparently standard practice here and I am being pressured to allow the automatic update apply SP2 to the SQL server clusters. I am very interested to hear from this community if they have used windows automatic update to patch critical servers. If you do use it and it is awsome I would like to know about that as well.
Cheers,
June 22, 2011 at 5:49 pm
No - never...absolutely not.
First, although rare there have been a few occasions where applying a service pack broke existing code in the application. Service Packs should always be thoroughly tested in a UAT/QA environment prior to scheduling and applying to a production box.
Second, you have no control over when the service pack is going to be applied. Windows update could apply the update during the busiest time of business. Also, what happens when a service pack is applied and your backups are running? You going to accept interrupting your backups so the service pack can be installed? Then, what happens when (not if) - the service pack update fails and you have NO backups to restore from?
And finally, service packs must be applied in a specific manner on a cluster to avoid causing issues. Especially with the way service packs are now applied to SQL Server 2008 - where you have to apply the service pack to the passive node first, failover, then apply to the other node.
Since I have never seen Microsoft release a SQL Server Service pack through Windows Update - I am not sure that is what you are talking about. If you are talking about upgrading the OS to SP2 - then my answer is still the same. Too easy to have your cluster trashed because of a bad update or some other problem.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 24, 2011 at 12:59 pm
thanks Jeffrey. I totally agree. You probably haven't seen SQL service packs in the windows update because your thoughtfull IT peers have filtered them out.
My question was intended to find supporters of the notion that this is not the way to patch your SQL server clusters. Anyone?
June 24, 2011 at 3:14 pm
I must admit that up until now I haven't had many problems with applying service packs themselves to my sql instances. (never needed to roll back/restart)
:KNOCK ON WOOD: :throw salt over shoulder: ... you know the drill after such kind of statements:hehe:
But some of our applications haven't !
So, automatic update ? No way !
I've also noticed with my last sp on a cluster, I needed to reboot the nodes after the first instance got upgraded. I didn't plan for the other instances to also upgrade at that point in time, so that caused me some problems because of the unintended down time.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
June 24, 2011 at 3:21 pm
seconded, thirded, fourthed and fifthed. Not for service packs, nada.
These need applying in a controlled manner at agreed times, backups taken, with testing afterwards and a backout in place.
Service packs do not contain ALL previous CUs so you could lose a fix you applied. You can also end up on different release paths and be totally screwed. I once had a long thread on here with someone who was totally unable to manually apply a patch because WSUS had automatically applied a previous patch that blocked it. Complete mess.
---------------------------------------------------------------------
June 25, 2011 at 11:53 am
george sibbald (6/24/2011)
seconded, thirded, fourthed and fifthed. Not for service packs, nada.These need applying in a controlled manner at agreed times, backups taken, with testing afterwards and a backout in place.
Service packs do not contain ALL previous CUs so you could lose a fix you applied. You can also end up on different release paths and be totally screwed. I once had a long thread on here with someone who was totally unable to manually apply a patch because WSUS had automatically applied a previous patch that blocked it. Complete mess.
I had the same issue - a hot fix was applied through WSUS and that particular hot fix blocked the SP3 upgrade.
Also, there was an issue with MSXML 6.0 a couple of years ago that cause SP3 to fail.
Either of those issues come up with an automated service pack upgrade, and the next morning you are going to be scrambling to get the system back up and operational with everyone looking over your shoulder.
I have also had issues upgrading clusters - where the upgrade appeared to be successful on node 1, but failed on node 2. The only recourse to fix that issue was to fail over to node 2, shut down node 1 and then rerun the service pack.
There are just too many things that can go wrong, that requires someone monitoring the process to validate and make sure it runs successfully. In most cases, these issues can be fixed fairly quickly - but you have to know the issue occurred before it can be fixed.
And finally - who controls when the servers are restarted? Can you imagine your database server being restared at 8am as all of your users are trying to start up for the day?
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 28, 2011 at 12:35 pm
Of course, even those who never allow SQL SPs to go in via automatic updates can get hosed. June 14th MS released a big security fix to SQL Server 2005 and 08 for all supported service packs, but buried it inside an XML Editor patch, so no one noticed the SQL patch on the Server team (which is separate from the DBA team who is responsible for the SPs). And as mentioned above, its application has wreaked some havoc on our environment, primarily in updating prod before dev in some cases, or only updating one of two cluster nodes, depending upon the schedules for the boxes. Anyone else have any issues with this release? Looks to me like MS kind of botched this.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply