On Thu, 2005-01-27 at 16:33, Raimund Jacob wrote:
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`
Thanx, I'll improve my script.
... 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
I know it does, but it doesn't seem to affect the import. We have
executed failovers during our DRP tests and everything was there up to
the last commit.
The actual failover script (this is another script) copies, just before
the backupinstance is brought online, also the online log files from the
failed instance. This way we can recover up to the last commit.
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?
I'd like to know too
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
My pleasure.
Regards,
Filip
--
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]
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
* System Engineer, Verzekeringen NV *
* www.verzekeringen.be *
* Oostkaai 23 B-2170 Merksem *
* 03/6416673 - 0477/340942 *
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
