Hi,

I'd like to amend Andy's comment to 'strongly recommend using ADSM
mirroring... with the MIRRORWRITE LOG SEQUENTIAL option '. We had a
number of recovery log corruptions recently (due to hardware problems),
and even though we were using ADSM mirroring, we were unable to restart
our server, due to a partial write in the recover log, and had to
restore to our most recent database backup. My personal opinion is that
if you cannot tolerate many hours of down-time restoring your database,
then you really do not have any choice but to 1) use ADSM mirroring and
2) use MIRRORWRITE LOG SEQUENTIAL. When we change from MIRRORWRITE LOG
PARALLEL to MIRRORWRITE LOG SEQUENTIAL, we did not notice any
significant performance degradation. And we push our ADSM servers pretty
hard.


Trevor
------------------------------------------------------------------------
------------------------------------------------
------------------------------------------------
Trevor Foley
Trevor Foley
Bankers Trust Australia Limited
Phone: 61-2-9259 3944    Fax: 61-2-9259 2659


        -----Original Message-----
        From:   Andrew Raibeck [SMTP:storman AT US.IBM DOT COM]
        Sent:   Thursday, June 11, 1998 5:48 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: Recovery log error ANR0209E on server
startup

        Usually I recommend using ADSM mirroring. When mirroring is
controlled by
        something other than ADSM, that "something" (hardware or
operating system)
        isn't smart enough to detect partial page writes that could
result in
        corruption; it just automatically mirrors the volumes,
corruption and all.

        ADSM mirroring with the MIRRORWRITE LOG SEQUENTIAL option in the
server options
        file is intended to prevent partial page writes from making it
to all copies of
        the recovery log. With MIRRORWRITE LOG SEQUENTIAL, a page has to
be
        successfully written to one copy of the recovery log before it
will be written
        to the other. So if ADSM is in the middle of writing a page to
one of the
        recovery log copies when it goes down, the update to the other
copy(ies) does
        not occur. Upon restart, if ADSM can't read the data from one of
the recovery
        log copies, it should be able to get it from another, then
resynchronize all
        copies.

        One caveat with this is that there may be a performance penalty
with
        MIRRORWRITE LOG SEQUENTIAL (as opposed to MIRRORWRITE LOG
PARALLEL). Writing in
        parallel may offer better performance, but it won't prevent
partial page writes
        from being written to all log copies. So you should run some
performance tests
        before committing to the SEQUENTIAL write strategy. I think I
saw someone post
        once that they saw only a negligible difference, but it's best
to see how it
        works in your shop.

        By the way: by default the database writes sequentially and the
recovery log
        writes in parallel.

        Andy

        Andy Raibeck
        IBM Storage Systems Division
        ADSM Client Development
        e-mail: storman AT us.ibm DOT com



        ADSM-L AT VM.MARIST DOT EDU on 06/10/98 12:32:03 PM
        Please respond to ADSM-L AT VM.MARIST DOT EDU
        To: ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject: Recovery log error ANR0209E on server startup


        Our configuration is ADSM 2.1.5.15 on AIX 4.1.5.  Our RS6000
died today