ADSM-L

Re: MIRRORWRITE option

1998-03-30 19:50:43
Subject: Re: MIRRORWRITE option
From: Trevor Foley <Trevor.Foley AT BANKERSTRUST.COM DOT AU>
Date: Tue, 31 Mar 1998 10:50:43 +1000
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



<Prev in Thread] Current Thread [Next in Thread>