HI Thomas,

I think that you have the same (incorrect) understanding of an ADSM
database point in time restore that I had until I was bitten a month or
so back. The date/time that you specify only select which database
backup(s) to restore from; it doesn't allow you to nominate a point at
which the recovery log should be rolled forward to.


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


        -----Original Message-----
        From:   Thomas A. La Porte [SMTP:tlaporte AT ANIM.DREAMWORKS DOT COM]
        Sent:   Thursday, May 28, 1998 2:30 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: Server Crash!!

        In Scott's case, would it be possible to
        'dsmserv restore db -todate=xx/xx/xxxx -totime=xx:xx' in order
to
        rollforward up to the point before the corrupted transaction?

        Presumably it is the last transaction that contains the
        corruption, and the rest of the recovery log is intact. It would
        certainly be a shame if the whole of the log had to be discarded
        because of one inconsistency at the tail of the log.

        As an example, under Oracle recovery is possible at the
        transaction level. When restoring from a backup and logs, one
can
        step through the logs one transaction at a time, and end the
        recovery at any point.

         -- Tom

        Thomas A. La Porte
        DreamWorks SKG
        tlaporte AT anim.dreamworks DOT com

        On Wed, 27 May 1998, Jason Meaden wrote:

        >G'day Scott,
        >
        >You have a corrupt recovery log due to a partial write that was
in progress
        >when the system died.
        >
        >You should probably restore the DB from your last backup.
Don't bother with a
        >rollforward, even if you had that enabled.  It will probably
roll in the same
        >error, and the server would still not start.
        >
        >You could also do a 'dump load audit' but this is very time
consuming.
        >
        >To prevent the problem occuring again, you could mirror the
recovery log and
        >use:
        >
        >MIRRORWRITE LOG SEQUENTIAL
        >
        >ADSM will then ensure that one mirror copy has been properly
written too before
        >beginning to write to the next.
        >
        >Regards,
        >--
        >  Mr Jason E Meaden                                  IBM
Australia Ltd
        >  Software Service Specialist (Asia Pacific)         55 Coonara
Avenue
        >  IBM Certified Specialist - ADSM             West Pennant
Hills  2125
        >  Phone: 13 24 26 * Fax: 61 2 9354 7797 * Tie: 49427 * VM:
RTP(MEADEN)
        >
        >
        >
        >
        >
        >ADSM-L AT VM.MARIST DOT EDU on 27/05/98 19:18:11
        >Please respond to ADSM-L AT VM.MARIST DOT EDU
        >To: ADSM-L AT VM.MARIST DOT EDU
        >cc:
        >Subject: Server Crash!!
        >
        >
        >Help,
        >
        >We have an NT4 SP3 server running ADSM 3.1.0.2 server.
        >
        >It has been running fine for ages up until last weekend.
        >
        >The ADSM server crashed with a Dr Watson error relating to
DSMSERV.exe.
        >
        >When we restart the server we get the following message
        >
        >ANR0990I ADSM server restart-recovery in progress.
        >ANR0200I Recovery log assigned capacity is 500 megabytes.
        >ANR0201I Database assigned capacity is 2004 megabytes.
        >ANR0306I Recovery log volume mount in progress.
        >ANR0353I Recovery log analysis pass in progress.
        >ANR9999D pkthread.c (825) : Run-time assertion failed:  "Cmp64
(
        >scanLsn, LOGV->headLsn )  != GREATERTHAN" , Thread 0, File
logread.c,
        >Line 364.
        >
        >Any help would be much appreciated
        >
        >Regards
        >
        >Scott
        >
        >
        >
        >
        >