Wait, I thought the assumption was that if you used the
rollforward mode and allowed it to restore to the most recent
point in time it would roll in the same error which caused the
crash in the first place. My question would be, when using the
"totime" option of 'dsmserv restore db', assuming that you are
running in rollforward mode, can you restore to a point in time
right *before* the error which caused the crash?
-- Tom
Thomas A. La Porte
DreamWorks SKG
tlaporte AT anim.dreamworks DOT com
On Thu, 28 May 1998, Jason Meaden wrote:
>G'day Tom,
>
>Yes it does, but no it won't.
>
>It will restore the database to the last DB backup up to an including that date
>and time.
>
>If you had done a Full DB backup at say 1:00am, then an incremental every hour,
>on the hour, and the machine passed away at 8:18am. You could specify a totime
>of, say, 8:15am, it would then restore the DB to the state it was in at 8:00am.
>
>However, if you did a full DB backup at 1:00am, but nothing since, and the
>machine passed away at 5:45pm, even using a todate and totime of 5:40pm, it
>would still only restore the DB to the state it was in at 1:00am - you lose
>over 16 hours of updates.
>
>All the above is assuming you had no valid recovery log. If you had a valid
>recovery log and had rollforward enabled, you could restore the DB right up to
>the state it was when the system died.
>
>This is an important factor in planning for availability of your ADSM server.
>Everyone should probably have a look at their setup and rethink what they are
>currently doing.
>
>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 29/05/98 03:04:30
>Please respond to ADSM-L AT VM.MARIST DOT EDU
>To: ADSM-L AT VM.MARIST DOT EDU
>cc:
>Subject: Re: Server Crash!!
>
>
>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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
|
