Why do you think this?
"The failure I see of this system is that even though the db is
paused, it
is not in a "safe" state for backup."
Once you broke the mirror would it not be safe to backup that array??
The db is basically in "mid sentence". The commits are not atomic.
If you restore to the tape, you may in my case have "half an order" or
an invoice half processed. the unidata dbpause does not make people
get out of maitnenance screens or release locks, so records can be in
an uncommitted state. Risk is small, but it is present.
Yes, have integrity at the UD & OS level , but application layer may
lack integrity at the logical transaction level.
I don't know UD, but on UV this can be mitigated by using Transaction
Logging in simple checkpoint mode, if nothing else. Your programs do
not need to have transaction start/commit structures to take advantage
of this. This is really "update", not "transaction", logging.
I administered a system that didn't use Transaction Logging because of a
bug (I think it's been fixed). We decided that our ap could live with
a couple half baked transactions in the event of a restore, so we used
the same double mirror/pause/split/tape backup as described by others,
with one variation: We left the mirror split and stale for most of the
day. That way if problems arose (e.g., broken file, file cleared
inappropriately, etc.) I had fast access to the previous day's data. I
occasionally took advantage of that feature. We never had a
catastrophic failure during my tenure, but restoring from the stale
mirror would have been much faster than restoring from backup tapes.
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
