Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Fear Fear Expand / Collapse
Author
Message
Posted Tuesday, June 4, 2013 9:00 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:49 PM
Points: 31,161, Visits: 15,607
Comments posted to this topic are about the item Fear Fear






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1460016
Posted Wednesday, June 5, 2013 4:26 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, October 13, 2014 6:12 AM
Points: 841, Visits: 332
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.
Post #1460134
Posted Wednesday, June 5, 2013 5:51 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:33 AM
Points: 5,565, Visits: 3,408
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!!!
Post #1460181
Posted Wednesday, June 5, 2013 6:14 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, June 11, 2013 6:49 AM
Points: 31, Visits: 158
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.
Post #1460194
Posted Wednesday, June 5, 2013 7:23 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, August 6, 2014 4:37 AM
Points: 520, Visits: 1,677
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
Post #1460229
Posted Wednesday, June 5, 2013 8:16 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, October 6, 2014 12:06 PM
Points: 2,907, Visits: 1,831
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.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1460249
Posted Wednesday, June 5, 2013 9:27 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, October 10, 2014 3:09 PM
Points: 371, Visits: 971
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
Post #1460279
Posted Wednesday, June 5, 2013 9:36 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, October 3, 2014 2:23 AM
Points: 3,108, Visits: 11,503
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.


Post #1460289
Posted Wednesday, June 5, 2013 9:42 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:49 PM
Points: 31,161, Visits: 15,607
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.








Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1460296
Posted Wednesday, June 5, 2013 10:26 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, October 10, 2014 7:31 AM
Points: 492, Visits: 812
<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
Post #1460322
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse