determine needed logbackup (was: crash during log recovery)

> -----Ursprüngliche Nachricht-----
> Von: Raimund Jacob [mailto:Raimund.Jacob@xxxxxxxxx] 
> Gesendet: Freitag, 18. Februar 2005 08:35
> An: Brunzema, Martin
> Cc: maxdb@xxxxxxxxxxxxxxx
> Betreff: Re: AW: AW: crash during log recovery
> 
> 
> Raimund Jacob wrote:
> 
> hello Martin, hello *,
> 
> > i'll just wait patiently for you to fix this. it's no 
> problem unles sit 
> > happens on the live system.
> 
> now it happened on the live system :(

What happended? The error you found affects only recovery.
So did you recover your live system and get the same error?


> 
> webpts is currently down, so i wonder if i can wait for a fix 
> in a new 
> release soon or if i rather should implement a workaround.
> 
> i assume the workaround would be to not only recover logs in 
> the standby 
> instance but also to recover full backups at regular intervals 
> (nightly). so each night transfer a full backup, and perform log 
> backup/recovery during the day.
> 
> this sounds like it's scriptable. but then: some of the log 
> fragments on 
> disk do not need to be recovered from (since they are from before the 
> full backup). can you please sketch the way a script might work? i 
> assume it's something with looking at db_restartinfo to find the last 
> log page, then somehow find the corresponding log fragment and start 
> from there. but i'd rather not guess this.

the easiest way to get the information which data/logbackups you need
is to use
        backup_history_list -r last
If you issue this command on the live-system then it may occur that
no logbackups are needed, because all relevant logentries are found
on the logvolume.
If you copy the file dbm.knl and dbm.mdf to your shadow, then the
command should work properly on the shadow.

Your're right that the information given by db_restartinfo is needed to
determine which logbackups are needed:
"Used LOG Page" is the LogIOSequence, which defines the first logpage needed
to restart.
"First LOG Page" is the first LogIOSequence found on the LogVolume. For your 
shadow this should be 2147483647 - which is a special value for invalid.

Another way is not to use db_restartinfo, but parse the backup-history
in dbm.knl. There are also all informations found (Savepoint-iosequence of the
backup and the the range of iosequences which are contained in the logbackups.

kind regards, Martin

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=gcdm-maxdb@xxxxxxxxxxx