Re: scripted log backup/recovery

Filip Sergeys wrote:

hey Filip, * !

i created my own script now, your one was of great help. here is what i 
made differently:

> 2) dynamically build a command script that will be executed by dbmcli in
> the very last step. Start with bringing database in admin mode and do
> util_connect

that's what i do now, too. that's just the second-best solution since 
you cannot detect errors when they happen. but see below..

> 3) look for the counter file and extract the lognumber of the last
> applied log file

i do not use a counter-file. i look at the backup-history to find the 
last successfully imported log fragment. works somehow like this:
backup_history_open - make sure to see the current version
backup_history_list -c LABEL,ACTION,RC -Inverted > $tmp

                          type-v   v-fragment v-action  v- error code
l=`tail +3 $tmp | sed -e 's/^LOG_\([0-9]*\)|RESTORE *| *0|/\1/' -e t -e 
'/.*/d' | head -1`

... now $l is the last fragment. this of course works only when the 
history-list page we look at contains the matching line. my script fails 
when it detects that it cannot parse this one page.

> 4) build a loop that scans over every .arch file (archived logfile)
> 5) if the lognumber in the .arch file is lower than the last applied log
> number -> skip it
> 6) if the lognumber in the .arch file is equal to the last applied log
> number -> apply that log again. (this is needed because then you are
> sure to have applied the last log PAGE, as already described in earlier
> mails). The first log you apply should always start with "recover_start
> ARCH LOG $lognr"

yep.

> 7) subsequent logfiles are applied with the command "recover_replace
> ARCH </path/to/logfiles/> $lognr"
> 8) update your counter file with the last lognumber you applied
> 9) end with recover_cancel
> 10) util_release (don't forget this one)
> 11) bring the database back to sleep
> 12) execute the dynamically build script

yep.

to make sure that inserting my logs worked out, i check the backup 
history again to see if the last fragment is indeed the last file i 
tried to import. if there is a mismatch, i abort and show both the 
script and the result. but it didnt happen, yet.

so this works, hooray. but: my DB crashes every time. i even changed the 
LOG_SEGMENT_SIZE in both instances (let it be determined automatically). 
no change. but the crash seems to do no harm.

filip: may i ask you to check your knldiag.err for lines like this:

2005-01-27 16:44:37 18778 ERR     8 Admin    ERROR 'cancelled' CAUSED 
EMERGENCY SHUTDOWN

perhaps your kernel crashes too, but you dont notice because you 
db_offline it in any case.

sap-folks: is this supposed to happen? anything i can do to prevent it?

what i need to do now is to run export/import cycles automatically for 
several days and see if this really works :)

thanks for your help,
        Raimund

--
7. RedDot Anwendertagung der RedDot Usergroup e.V. am 31.1.2005
Pinuts präsentiert neue Entwicklung, http://www.pinuts.de/news

Pinuts media+science GmbH                 http://www.pinuts.de
Dipl.-Inform. Raimund Jacob               Raimund.Jacob@xxxxxxxxx
Krausenstr. 9-10                          voice : +49 30 59 00 90 322
10117 Berlin                              fax   : +49 30 59 00 90 390
Germany


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