>On   Friday, September 23, 2005,   Craig Dudley   sent forth:
>
>>
>>>
>>>But I just want to be clear to anyone else reading the list (lurkers et
>>>al) that your statement of "I don't think PowerMail or other well-written
>>>applications behave like this" simply isn't true. Very well-written
>>>database engines keep files open, and yes, a crash or cut to power can
>>>leave those files unusable. But I'd like to stress for the technical out
>>>there (and there seem to be plenty on this list) that that's not an
>>>indication that the app is flawed; it's simply the nature of databases.
>>>
>>
>>Uh, I disagree. I work with lots of database managers that pride themselves
>>of being able to recover back/forward to a specified point-in-time. That is
>>a *requirement*.
>>
>>
>
>
>The "nature of databases" and the "pride of database managers" are two
>mutually independent things.
>
In this example, database managers (DBM) are software, not people. Examples 
are DB2 for z/OS, DB2 UDB, IMS for z/OS, Oracle, MySQL, SQLServer, etc. The 
"pride" being talked about is their developers pride in their engineering 
effort to prevent database corruption (due to simple things like loss of
power). 
They use various techniques such logging, live image copies, etc.

>Databases ARE prone to corruption in the event of a power failure or
>other such unexpected interruption.  This cannot be disputed.
>
All reasonable DBMs can be recovered back/forward to a specified point-
in-time.
As said above, all reasonable DBMs use techniques to make sure database
corruption doesn't occur.

>
>What the people who run them do about this issue is quite another thing
>and should not be confused with the above statement.  These people might:
>    run scripts to "pause" the database while a copy is being made or use
>an equivalent built-in feature that the vendor supplied with the main
>application.
>
>    use disk mirroring to guarantee that what is written on the main disk
>is almost simultaneously written to a recovery disk somewhere else in the
>organization.
>
>    use some other option
>
>
>In short, the database managers, bless their tired little souls, might
>indeed be proud of what they do but that does not change the fact that an
>open file is always facing the risk of damage due to improper handling,
>whatever the cause might be.
>
>The statement you made is akin to someone saying the weather vary wildly
>and you disagreeing by saying that meteorologists take pride in their
>work.  One does not negate the other.
>
>-- 
>Tim Lapin
>[EMAIL PROTECTED]
>
>

-- 
Craig Dudley
Systems & Communications Sciences, Inc.
244 Poor Farm Rd.
New Ipswich, NH 03071-3922
603-878-1148           Fax 603-878-1929




Reply via email to