ADSM-L

Re: Server Crash!!

1998-05-27 20:48:36
Subject: Re: Server Crash!!
From: Jason Meaden <jasonm AT AU1.IBM DOT COM>
Date: Wed, 27 May 1998 20:48:36 -0400
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
  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
>
>
>
>
>




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