November 11, 2009 at 12:25 am
Comments posted to this topic are about the item A Better Way To Install Updates
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 11, 2009 at 12:44 am
Steve,
While I normally find myself nodding in agreement with most of what you write in the editorial, today is an exception to that; while I can see how not applying patches can definitely 'save' time in the short run, this time will be wasted when a problem occurs. Suddenly a problem can threaten the stability of the system running and frustrate application managers and developers, followed by out-of-schedule updates (as in: late-night work, when the office is empty).
But perhaps I'm biased due to being a developer...
--K
November 11, 2009 at 5:43 am
If an error occurs and you get to know about it, that is as should. What is more risky with patching with the latest directly without waiting or testing is the logical errors that sometimes takes place and stays hidden and only shows themselves within the results or so.
That's my thoughts about it in short...
November 11, 2009 at 8:26 am
I think you're mis-reading me a little. I said that I'd like to see the user informed that there is a patch available. There's no shortcut here of not testing, and a smart system could in fact, inform the user of all things that would be changed with the patch.
If you never hit an issue covered in any of the CUs, then why look at them or think about appying them?
The idea was to inform people that there is a fix when an error occurs, not necessarily have them apply updates for no reason, or have errors occur without doing any checking on possible solutions.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 11, 2009 at 8:28 am
Microsoft software sort-of already does try to link errors to solutions. When an error occurs, look at the Event Viewer. An error or other message (assuming one appears, that is) will (usually) contain a link to the "Help and Support Center", where presumably you'd be able to find information to help you resolve the error.
Now, that's all well and good, but unfortunately my experience has been that it's mostly useless, as when I go to the Help and Support Center I usually get something that tells me that there's no information on the error. Not always, but usually.
So, it seems like the framework is in place, it's just lacking content.
November 11, 2009 at 9:11 am
That might be true, though I don't think the Event Viewer actually queries for more up to date info. It would be good if you could allow queries to MS or WSUS for a check of the current error against patches out there and return results to someone.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 11, 2009 at 11:01 am
Hay Steve, you've got an interesting subject here. One thing I wanted to bring to everyone's attention is that in the Financial world, many companies have "certifications" associated with their networks. Those certifications often expressly require the corporation to install ANY patch classified as "critical" by the vendor (in our case Microsoft) within 30 days. So whether we like it, trust the testing or not, we often have to roll out Cumulative Updates to our SQL Servers with one month. :exclamation:
We do it by applying them to the Development servers within 3 days of release and then to the Production servers in the last week of the month - unless Development found a "show stopper".
As you can imagine, we've had our share of Heart-stopping events.
Keep up the good work, we enjoy your site and staff's efforts.
Drive it like you stole it[/size] :w00t:
November 11, 2009 at 12:51 pm
Wow, are the CUs classified as critical? I didn't think that applied to most of them.
Thanks for the kind words.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 11, 2009 at 3:05 pm
Maybe the "Cloud" will save us from the endless treadmill of patches, CU's, SP's, security updates and version upgrades. No, seriously.
James Stover, McDBA
November 11, 2009 at 3:44 pm
Steve, a lovely idea if it could be made to work.
[But perhaps I'm biased due to being a developer...
In this case yes I think so.........
applying a patch for a problem you don't have risks unnecessary problems and will cause an unnecessary outage to apply the patch.
@martinrc - I am sure CUs are not posted as critical. only service packs and some security patches would be. You may be constantly patching for no reason here........
On a related note, is it me, or do MS provide a lot less info about patches then they used to in the good old pre version 8.00.990 days? where have the readme files gone? where do they tell you if the patch updates system databases and stops and starts SQL or if exclusive access is required.? A case in point is the recent MS09-062 which even though it is a security patch does log into SQL and leaves the services down. How do I know if I can leave application of the security patch to an automated tool such as WSUS or have to manage the patching process manually. Its a real pain when you have a lot of servers and have to arrange application downtime.
Perhaps the pop-ups could also let you know that as well 🙂
---------------------------------------------------------------------
January 19, 2010 at 10:38 am
Steve Jones - Editor (11/11/2009)
That might be true, though I don't think the Event Viewer actually queries for more up to date info. It would be good if you could allow queries to MS or WSUS for a check of the current error against patches out there and return results to someone.
Event viewer doesn't, but the page it sends you to does.
Unfortunately, as dmbaker said, it usually doesn't find anything; even worse, when it does find something it's usually completely irrelevant.
So far as not applying current updates goes, the only problems I've had when updating SQL 2000 and MDAC with all updates was that over time the system get less tolerant of sloppy (technically incorrect) use of ADO, like trying to use a forbidden record set (cursor) property combination; that of course wouldn't have been a problem if the code had been written correctly in the first place, or if the system had complained when the offending code was new instead of a few years later; or if indeed the restrictions had been documented somewhere where the developers stood a reasonable chance of finding them (in typical MS fashion, they were buried somewhere where most developers would have had difficulty in finding them, even if they had looked for them - which of course they hadn't as they had decided to play "safe" and use the defaults, not being aware that MS had provided defaults that produced a forbidden combination of properties).
And I ensured that our contracts with our customers included a requirement that the arrange server downtime for us to apply updates that we considered critical (whether from us, from MS, of from any other supplier of software or firmware components of the systems). I can't see how we could have supported our customers otherwise.
Of course I am biased on this topic - my experience in the year beginning June 2002 (back when I was in charge of Research but not Development or Support) when I argued for the application of all critical updates and lost, and then watched while our failure to apply either of MS02-039 and MS02-062 allowed the slammer worm to take down all our customers' databases and our own servers too, ensures that I'm in favour of early application of fixes. OK, so those were critical patches, but the effect of not having them was pretty spectacular (at the end of Jan 2003 the the half-life of an SQL Server without the patch when it was connected to the internet and port 1434 was unblocked on the firewall was less than a second). There were less spectacular problems arising from non-critical updates like, for example deadlocked queries where deadlock was not detected so the database hung until one of the queries timed out, for which there was a perfectly good and safe hotfix which we really needed (longish MIS queries were run against live databases at times when OLTP demand was expected to be low, so reducing the query timeout was a non-starter) - this generated customer complaints about slow response (nothing as spectacular as slammer, but still a lot of pain) - but if I couldn't get critical fixes applied what chance had I on non-critical ones? So by the time I was in a position to determine fix application policy the pain of the preceding months ensured that even if I hadn't already favoured incremental development and release (and hence of early application of fixes) I was now biased in favour of early application. Of course that has to be subject to review and assessment of risks and appropriate testing in the light of that assessment - for example we delayed application of Win2003 SP2 on customer's servers for almost 12 months while we tested extensively in house. And nothing that happened since we started upgrading servers quickly has made me think that this is the wrong approach. So I tend to disagree with the approach in the editorial.
Tom
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply