Yes, but doesn't the 'dsmserv restore db' command also accept a
"-totime" parameter, which would allow Scott to specify a time
right before his crash?

 -- Tom

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


On Wed, 27 May 1998, Jason Meaden wrote:

>G'day Tom,
>
>Yes, and no.  But mainly no.
>
>This would restore the DB to the latest DB backup up to and including the
>specified date.
>
>In other words, it would apply the last full DB Backup, plus any incrementals
>up to the specified date.
>
>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 28/05/98 02:48:57
>Please respond to ADSM-L AT VM.MARIST DOT EDU
>To: ADSM-L AT VM.MARIST DOT EDU
>cc:
>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
>>
>>
>>
>>
>>
>
>
>
>
>