May 4, 2009 at 12:29 pm
I'm sure this has been discussed and I missed the posts. Our Systems team installed some Microsoft updates to our production log shipping standby sql box over the weekend. I suspect these had been sitting, waiting for install for quite a while ( our production boxes don't install updates automatically ).
So SP3 for SQL 2005 was installed "inadvertently" but has not been installed on our other production sql boxes. If you want to refer me to older posts on this that will be fine, but I'm looking for a discussion of how Microsoft arrived at this new approach. It would seem that a service pack installed "accidentally" that caused some sort of production outage could be grounds for a law suit.
May 4, 2009 at 12:44 pm
I don't think you'd win such a lawsuit. If auto updates are enabled, you have instructed the OS load patches/updates. If you haven't, and it installed along with other patches/updates, then someone failed to review what patched were going to be applied.
Regarding when Microsoft added SQL Server to using Windows Update, this occurred with SQL Server 2005. It was done to make, supposedly, patching Microsoft SQL Server easier for admins. I have found it makes my job a bit easier.
May 4, 2009 at 1:04 pm
If installing a sql service pack has the potential to break things, then it should be installed in Dev and tested first. Perhaps this is no longer a big concern. If it is, then bundling the SP in regular OS patch updates seems risky and undesirable from a DBA standpoint.
Randy
May 4, 2009 at 1:10 pm
Indianrock (5/4/2009)
If installing a sql service pack has the potential to break things, then it should be installed in Dev and tested first. Perhaps this is no longer a big concern. If it is, then bundling the SP in regular OS patch updates seems risky and undesirable from a DBA standpoint.Randy
I install all SP's on our test servers manually first. The fact that it can be applied with Windows Update (controlled by our Network Services department) means I don't have to install the service packs manually on all our servers. Once I have verified it works in our test environment, they can handle the updates from there automagically.
As for my personal installs on my systems at home or here on my desktop system at work, I let Windows Update handle it for me. It serves as my first test.
May 4, 2009 at 1:51 pm
Thanks Lynn. I have difficulty getting the resources to install sql on a test box and actually having it "exercised." Also, our systems team is not used to having to check with anyone else before installing what they consider primarily OS or IE patches.
But, that's our problem. Yet another small company, now mid-sized with no official DBA and no long track record of dealing with SQL Server. :w00t:
May 4, 2009 at 2:50 pm
what worries me about allowing automatic updates of SQL service packs is where's the backout? system DBs should be backed up first, and a copy of the resource database taken for ease of recovery and DR purposes. there is also app testing afterwards.
Service packs reliability at install have improved in recent times but an upgrade is never 100% risk free (e.g. what if people are connecting when the upgrade is running?)
I have also seen problems reported on this site where attempts to apply a hotfix have failed because WSUS has already applied a fix from the GDR path and the fix required was on the QFE path.
---------------------------------------------------------------------
May 4, 2009 at 3:26 pm
The problem I had with the install of SP 3 on a test server wasn't related to WSUS loading something, what was missing was the .msp files from the install of SP 2. That was done manually on both servers when SP 2 was released so i have no idea how the files disappeared from the Installer directory.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply