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»»

Uptime = Downtime? (Database Weekly, Aug 3, 2009) Expand / Collapse
Author
Message
Posted Saturday, August 1, 2009 11:09 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 4:02 PM
Points: 33,062, Visits: 15,176
Comments posted to this topic are about the item Uptime = Downtime? (Database Weekly, Aug 3, 2009)






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #763627
Posted Saturday, August 1, 2009 1:08 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 6:12 PM
Points: 36,750, Visits: 31,198
This is a good subject. The military realized the fallacy of "If it ain't broke, don't fix it." a long, long time ago. Daily, weekly, monthly, quarterly, yearly, and "as required" maintenance procedures for virtually every piece of equipment is available, scheduled, and required to be completed. It's why we win wars... it helps keep stuff from breaking when you can least afford it to.

It's too bad that most people don't consider the same with most software. Good DBA's do by checking their overnight "health check" runs and whether or not their permanent "low hanging fruit" profiler run for RPC Complete and SQL Batch Complete picked up anything out of the ordinary. Good GUI designers will also put parametrics into their system to measure and log such things as the time it took to render and present a page, etc.

Sadly, not enough people take the time to do all of that. All they really care about is "time to market" and "it's good enough for this release". Rarely do they care about future performance (including up time) and the like because they don't even care about it in the present. "Wrap it and ship it" has become the mantra for many. "Set it and forget it" is the normal follow up to that.

"If you want it real bad, you'll likely get it that way." -- Jeff Moden, circa 2003



--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #763654
Posted Monday, August 3, 2009 5:36 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Sunday, May 4, 2014 7:48 PM
Points: 369, Visits: 217
" It's why we win wars... "

We do?

I always thought in software it is a golden rule not fallacy. 'if it ain't broke don't fix it'. Maybe it is a fallacy for hardware but not software.
Post #763987
Posted Monday, August 3, 2009 7:09 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, November 11, 2013 2:42 AM
Points: 150, Visits: 245
The key thing is that the maintenance schedules that all modern armies use are based on solid statistical studies, and a good understanding of the design specifications.

In contrast, Formula 1 teams have discovered that they used to be doing things all wrong: it was standard practice to strip an engine down after every race to check for defects, but recent rule changes that meant an engine had to be able to last for more than one race, actually made them more reliable - those that had lasted one race distance had proved themselves to be free from major defect, and were better left alone. Those that were rebuilt had an increased risk of a fault being introduced.



Throw away your pocket calculators; visit www.calcResult.com

Post #764032
Posted Monday, August 3, 2009 7:56 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 4:02 PM
Points: 33,062, Visits: 15,176
software shouldn't break down like hardware does, but it always has defects in it. If we continue to delay fixing software, often we are building on a poor foundation and we cause a similar issue with "large downtime", but not addressing issues we're aware of.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #764065
Posted Monday, August 3, 2009 8:30 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, November 11, 2013 2:42 AM
Points: 150, Visits: 245
Steve Jones - Editor (8/3/2009)
software ... always has defects in it.


Indeed, but the point I was trying to make was that by that same token, your fixes will also have defects, and sometime it is 'Better the Devil you know'.

As a rule, I find that there always plenty of 'improvements' that I can make to the things I look after, without needing to deal with other peoples mistakes.

A further point would be that most of us have to abide by ITIL or similar, under which the kind of tinkering that you seem to be suggesting would be likely to get you fired.



Throw away your pocket calculators; visit www.calcResult.com

Post #764094
Posted Tuesday, August 4, 2009 11:37 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: Today @ 11:18 AM
Points: 3,193, Visits: 2,289
It seems to be more of a case of avoiding 'planned downtime' in order to increase 'availability' while at the same time increasing the possibility and length of 'unplanned downtime'.

Check out the following:

http://en.wikipedia.org/wiki/High_availability

Lots of good links in the wiki ...




Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #765027
Posted Tuesday, August 4, 2009 3:10 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 6:12 PM
Points: 36,750, Visits: 31,198
umailedit (8/3/2009)
" It's why we win wars... "

We do?

I always thought in software it is a golden rule not fallacy. 'if it ain't broke don't fix it'. Maybe it is a fallacy for hardware but not software.


Heh... that's why I'm able to make a living. People think that working software won't break. Then, the data reaches a point that every computer has... it's called the "tipping point". That's where working software that has (supossedly) good performance suddenly has very bad performance. It also happens when folks can least afford for it to happen... month end runs, tax time, etc, etc.

Just like a truck, the bearings and suspension have to be able to "carry the load". In software, most people don't anticipate the load. The software runs just fine until one day, the load just gets too big and suddenly that proverbial truck breaks.

Part of software maintenance is to check the performance of the code now and again so that as data grows, you can see if the software is beginning to go non-linear in performance and a few other measurements. For example, if a screen was returning in a half second and it's suddenly returning on a consistent basis in a second, something with the data is likely the problem and it's warning you that you're likely to have a substantial performance problem in the future.

Bottom line is, working code can break... don't let it be a surprise when you can least afford it.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #765146
Posted Wednesday, August 5, 2009 4:07 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, November 11, 2013 2:42 AM
Points: 150, Visits: 245
Heh... that's why I'm able to make a living.


And how many times to you get brought in to sort out a system that had been 'upgraded' or 'fixed' by someone who had just been let go as a result?

Anyway, in the situation that you describe, the software has not 'broken'. A fundamental flaw that should have been uncovered in testing has been found.


Throw away your pocket calculators; visit www.calcResult.com

Post #765326
Posted Sunday, October 25, 2009 7:21 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 12:05 PM
Points: 8,556, Visits: 9,047
umailedit (8/3/2009)
I always thought in software it is a golden rule not fallacy. 'if it ain't broke don't fix it'. Maybe it is a fallacy for hardware but not software.

Maybe you are right - but I never yet saw any non-trivial sofware that wasn't broke and stayed that way for a significant amount of time (it ended up broke either because it had real bugs or because it had security problems or because new requirements had come or because the users didn't like it or because teh requirement specification was broke in the first place). And don't forget that a security flaw for which there are no exploits may leave the software looking as if it ain't broke, but when someone produces an exploit it will suddenly become obviously very broke indeed, so it's best to fix before that happens - so you have down time to apply and check patches even when the system ain't broke.




Tom
Post #808430
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse