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:[EMAIL PROTECTED] >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 [EMAIL PROTECTED] >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/[EMAIL PROTECTED] > > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
