Hi Andy,
Thanks for following up the documentation issue. That will at least
enable people to make an informed decision.
We are still working with IBM support to work out why both copies of our
log were trashed when a single device failed. I'm not yet convinced that
setting MIRRORWRITE LOG SEQUENTIAL is the whole answer. I'll let you all
know what we find.
Trevor
-----Original Message-----
From: Andrew Raibeck [SMTP:storman AT US.IBM DOT COM]
Sent: Saturday, March 28, 1998 5:05 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: MIRRORWRITE option
I am not privy to the reasons why PARALLEL was chosen as the
default for the
recovery log, while SEQUENTIAL is the default for the database.
My guess is
that it had something to do with balancing performance with
reliability, and
that the write characteristics of the recovery log are such that
SEQUENTIAL had
too much of a negative impact on performance to be a reasonable
default. Also,
the odds of both mirrored copies being taken out at the same
time are probably
less than those of losing a single copy, assuming that the
copies exist on
physically separate disks. So while under certain circumstances
PARALLEL may
offer less protection than SEQUENTIAL, it still does not negate
the benefits of
mirroring altogether. And for that matter, SEQUENTIAL is not
necessarily a
guarantee either since an outage that affects both copies, such
as concurrent
hard disk crashes or the machine goes up in smoke, would render
both copies
useless. So it's really a matter of degree of risk.
But all of that notwithstanding, I agree that the Admin Guide is
lacking in
this area. There is a section in the Admin Guide on mirroring
and how to
implement it, and it makes no mention of MIRRORWRITE. This makes
the discussion
incomplete, IMHO. So I have taken DOC APAR IC20497 to address
this.The APAR
requests that information on these options be added to the Admin
Guide, and
that the trade-offs (performance vs. level of protection) be
discussed.
Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
ADSM-L AT VM.MARIST DOT EDU
03/27/98 05:46 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: MIRRORWRITE option
>IBM support have recommended to us to change the MIRRORWRITE
LOG option
>in dsmserv.opt to sequential, rather than the default of
parallel, as
>there have been reported instances of log file corruption
where, by
>setting MIRRORWRITE LOG to sequential, the corruption could
have been
>avoided. If this is true, why have IBM not told their customer
base
>about this? Instead, they have created an extremely peeved
customer.
The "Installing the Server..." manual alludes to this, under its
description of the MIRRORWrite option:
Note: If a system outage occurs at exactly the instant that
each
mirror is partially complete in writing its page, a
partial
write to each mirror can result.
Allusion isn't enough, as you point out. Full ramifications
should be
discussed in the Admin Guide (including what happens during disk
malfunctions). That manual now only says that the option exists
and that you
should look in the "Installing the Server..." manual for info,
which is wimpy
documentation. I've tried to encourage customers to use
"MIRRORWrite
Sequential", in several posts to ADSM-L (without trying to sound
like a broken
record). In my view, serious ADSM implementations should be
doing mirroring,
and use of Sequential mode is the only sane approach. Responses
from some
customers have been that Sequential might hurt performance, so
they stick with
Parallel. Yet what's the point of mirroring if you implement it
in jeopardy
mode??
I think your valuable contribution of your painful experience
will help
convince others of what they are risking. To everyone who
hasn't implemented
these options: Don't wait for your own painful experience before
doing so.
Richard Sims, Boston University OIT
|