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
|
