Uptime = Downtime? (Database Weekly, Aug 3, 2009)

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Uptime = Downtime? (Database Weekly, Aug 3,...

12 posts, Page 1 of 2

1 2 »»

Uptime = Downtime? (Database Weekly, Aug 3, 2009)

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Saturday, August 01, 2009 11:09 AM

SSC-Dedicated

Group: Administrators
Last Login: 2 days ago @ 1:47 PM
Points: 31,406, Visits: 13,722

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

Jeff Moden

Posted Saturday, August 01, 2009 1:08 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893, Visits: 26,770

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

Wink

--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."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #763654

umailedit

Posted Monday, August 03, 2009 5:36 AM

Old Hand

Group: General Forum Members
Last Login: Tuesday, April 30, 2013 11:54 PM
Points: 367, Visits: 211

" 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

mike brockington

Posted Monday, August 03, 2009 7:09 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 4:49 AM
Points: 119, Visits: 213

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

Steve Jones - SSC Editor

Posted Monday, August 03, 2009 7:56 AM

SSC-Dedicated

Group: Administrators
Last Login: 2 days ago @ 1:47 PM
Points: 31,406, Visits: 13,722

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

mike brockington

Posted Monday, August 03, 2009 8:30 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 4:49 AM
Points: 119, Visits: 213

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

rudy - Doctor "X"

Posted Tuesday, August 04, 2009 11:37 AM

Hall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 2:11 PM
Points: 3,108, Visits: 2,114

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

Jeff Moden

Posted Tuesday, August 04, 2009 3:10 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893, Visits: 26,770

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

Post #765146

mike brockington

Posted Wednesday, August 05, 2009 4:07 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 4:49 AM
Points: 119, Visits: 213

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

L' Eomot Inversé

Posted Sunday, October 25, 2009 7:21 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 6:35 AM
Points: 7,078, Visits: 7,119

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
Que conclure à la fin de tous mes longs propos? C'est que les préjugés sont la raison des sots. (Voltaire, 1756)

Post #808430

« Prev Topic | Next Topic »

12 posts, Page 1 of 2

1 2 »»

Permissions