RE: scripted log backup/recovery

Hello Raimund,

As was confirmed by a colleague, you should not worry about:

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

That is the "normal" side effect of a recover_cancel in newer releases. So your 
script has to start the database after every recover_cancel again.

Best regards,
Tilo Heinrich
SAP Labs Berlin

>-----Original Message-----
>From: Raimund Jacob [mailto:Raimund.Jacob@xxxxxxxxx] 
>Sent: Thursday, January 27, 2005 4:34 PM
>To: Filip Sergeys
>Cc: MaxDB List
>Subject: 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=tilo.heinrich@xxxxxxx
>
>

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