Re: Data Constraints Vs Application Constraints

From: FrankHamersley <FrankHamersleyZat_at_hotmail.com>
Date: Sun, 13 Mar 2005 04:17:05 GMT
Message-ID: <59PYd.195064$K7.90771_at_news-server.bigpond.net.au>


David Cressey wrote:
> "FrankHamersley" <FrankHamersleyZat_at_hotmail.com> wrote in message
> news:yMBYd.194541$K7.26278_at_news-server.bigpond.net.au...
>
>

>>True - I'm not convinced the tools and techniques have advanced as far
>>as the demands.  My recent experience has been on systems that don't
>>have fat windows of free time to put the system into single user mode
>>whilst the schema is broken for a data fix so I like to avoid
>>intractable problems.  As you know Murphy's Law applies to these

>
> situations.
>
> True- Avoiding intractable problems is better than fixing them.
>
> As far as windows of free time, I'm quite dogmatic myself: 365x24 is a
> fool's paradise.
> You can't do all the routine maintenance on a big database whenever February
> 29 rolls around
> (subtle humor). Airliners are just as valuable as databases, and they
> regularly take them out of service for routine maintenance.

True - However they often fly them with lots of "known defects". By known I mean by issues that are identified problems before the aircraft is pushed back from the gate. They manage this with strong protocols around what type and quantity of defects is allowed. This is underpinned by double/triple/quad redundant systems and gets fixed at the next routine maintenance event.

Imagine running an airline with planes that refuse to take-off because an insignificant globe has blown in the cockpit.

> Expectations need to be lowered to the point where a DBA can meet them by
> being competent and professioanl, but without sacrificing a life in order
> to make a living.
>
> As far as tools go, I got spoiled early in this game by DEC Rdb/VMS. The
> tools it has (going back at least to 1990) for helping with diagnosis of
> errors, monitoring performance, and all the other DBA type work were quite
> advanced and superbly engineered. You had to be smart to use those tools.
> You had to be wise enough to realize that an ounce of prevention is worth a
> pound of cure. But you didn't have to work like crazy. Other products are
> coming along, but I still liked working with those tools.
>
I can sympathise - the art of installing/embedding telemetry in systems and then the art of reading the results effectively has sadly taken a back seat to the whiz-bang pursuit of feature sets and MHz. Maybe it might make a come-back one day!

Cheers, Frank. Received on Sun Mar 13 2005 - 05:17:05 CET

Original text of this message