June 5, 2013 at 4:26 am
Fear of change?
The only constant in life is change. Prepare for it, deal with it, learn from mistakes (if you make any).
Not applying service patches only gets you along so far. It's like not replacing oil and oil filter on a car - if you only drive a few miles each day that can last you a long time. Do it for a few thousand each month and you end up with a broken car.
Service patches = oil.
June 5, 2013 at 5:51 am
I think that applying intelligent selection to when changes occur (as opposed to if they do) is a key expertise within IT.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 5, 2013 at 6:14 am
In the past I've been responsible for Exchange, SQL, and Dynamics CRM. I've had the same concern about cumulative updates - even service packs. You know you need to, so you do the risk/reward algorithm.
The part of that that bites me though is when you decide the risk is not worth the reward, but then two CUs later, you need to roll-up because the most recent CU meets the risk/reward threshold; so you need to take on the risk you weren't willing to before, for the reward you want from the new one.
June 5, 2013 at 7:23 am
I think that there is a difference between the first set of issues (developer access, backup failure etc) and not maintaining a current patch level.
Its like most things, down to judgement - you don't want to be rolling out every SQL KB that comes along, while on the other hand not planning to apply the next SP until support runs out for the current one is not a good idear either - although mea culpa I have held back on upgrading from SQL2008 R2 Sp1 because there really hasn't been a need to and the SP on our estate has been very stable 😉
June 5, 2013 at 8:16 am
There is a saying in the Agile world. If it hurts do it more often.
What it means is that if you have a pain point then work through the process to improve it until it is no-longer a pain point.
I've just had a conversation about why we haven't rolled out Red-Gate source control. It boiled down to tech-debt in the legacy estate foxes it. Get rid of the tech-debt and all of a sudden the entire DB estate could be put under version control.
Sometimes you have to turn a problem on its head before you can see the way forward. Ask the 5 whys to get to the root cause of the fear and you may find that the solution is far simpler than you would first imagine.
June 5, 2013 at 9:27 am
I don't update things simply because there is an update available and we usually plan changes in advance as the servers are 24/7 so taking one down involves a lot of groups. Two minutes of downtime is five minutes too many as the saying goes. One thing I tend to do when it comes to changes is plan them and make them without telling anyone whenever possible. I do this because broadcasting a change will present the opportunity for people to report phantom issues or blame the change on something completely unrelated. That may sound nuts to many but it works well for me and if a problem is reported I'll know it is usually based on reality.
Change may be inevitable but that doesn't make change for the sake of change a good idea. Like most things, risk vs. reward should drive the decision.
Cheers
June 5, 2013 at 9:36 am
I take a conservative approach to applying SQL Server service packs.
I usually don’t apply them to a production environment until they have been out for a few months, unless I know they solve a specific problem we are having.
Otherwise, I like to wait so that Microsoft support has had most problems with the service pack already reported to them by someone else.
June 5, 2013 at 9:42 am
David.Poole (6/5/2013)
There is a saying in the Agile world. If it hurts do it more often.What it means is that if you have a pain point then work through the process to improve it until it is no-longer a pain point.
Except with some patches, it's not you that can eliminate the pain point easily. You're depending on the quality of someone else. Like CUs.
June 5, 2013 at 10:26 am
<opinion>
Microsoft released an update to XP (maybe 2000) that broke any PC running Norton or McAfee. Oracle released a flawed version of Java that was so bad Apple denied the ability to run that version on their products. Oracle followed up with a patch that was just as bad. Adobe patches come out so often it seems to be hourly, and each is worse than the one before!
</opinion>
Patches frequently fix major security flaws. They fix performance issues. They fix bugs that cause apps to crash.
As noted above, patches frequently break things, cause major security issues, cause performance issues, and introduce new bugs that cause apps to crash.
So seriously, if my system works, and I am not aware of any issues, why in the world would I apply a patch? No, really?
In my case, I support more than 20 different applications, more than 40 separate SQL Server database servers in production, almost as many test SQL Server servers, all spread out over more than 100 actual production Windows servers. So again, why would I patch something that isn't broken? No, really?
😀
Do we need to patch? Yes. Do vendors needs to step up and do even the smallest amount of testing before releasing patches? That would be nice. It will also be nice when the economy turns around (yeah I know, good luck!) and companies start hiring more staff to allow their staff to be able to actually be proactive instead of reactive. I think that will happen soon, or at least as soon as a purple dinosaur runs for president.
Dave
June 7, 2013 at 11:26 am
I've told this story before, but I will tell it again for the benefit of those who may not have heard it. I was in an interview for a DBA position down here in South Florida a number of years ago and the first thing out of the interviewers mouth once I sat down was "All of our developers here have sysadmin access to all of our production SQL Servers,. Do you have a problem with that?" I quitely smiled and said "Well sir, that explains why you are looking for a DBA. Thank you very much for your time." Shook hands with the gentlemen and promptly left. The bottom line is I don't waste my time on jobs where I get the distinct feeling I am probably walking into a "firestorm". Some DBA positions are OPEN for a REASON. So, be very careful out there what you may be getting yourself into. Yes, change in any shop is inevitable I suppose, but dysfunctional is something you can avoid if you learn to spot the signs. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply