Alexei, >-----Original Message----- >From: Alexei Novakov [mailto:[EMAIL PROTECTED] >Sent: Monday, June 21, 2004 9:39 PM >To: Hahn, Uwe; MaxDB mailing list. >Subject: RE: SAPDB Standby database setup. > > >Uwe, > >It sounds like everything goes OK. But the question >still persists why I am not allowed to start recovery >session from this savepoint? Why should I always start >recovery from the first log backup? Here is the >sequence of actions: > >util_connect >recover_start data_bak >util_release >util_connect >recover_start log_bak 001 >recover_cancel
The savepoint during redo saves the current redo read position. The last read position is the last iosequence of backup 001 >util_release >db_admin You can proof this by executing "db_restartinfo" at this time here and compare the "First Used" value with the backup history of log backup 001. "First Used" should be equal to the last iosequence of log backup 001 so you have to begin the next recover_start with log backup 001 again and then go on with recover_replace of log backup 002. >util_connect >recover_start log_bak 002 >... > >The result of last command is -7075. It asks for the >first log backup even though it was recovered already. >Is it the way it should be? If not, what am I doing >wrong? Yes, this is the way it should be. You should begin with the backup which is told you by db_restartinfo in comparison with the backup history. This is automatically done by the recovery wizard of the dbmgui. regards, Uwe > >Regards. >Alexei. > >--- "Hahn, Uwe" <[EMAIL PROTECTED]> wrote: >> Alexei, >> >> sorry I don't understand what you mean with "real >> reason". >> In the part of the knldiag you have appended you see >> the following lines: >> >> >> >2004-06-16 13:42:14 2452 WNG 18 Log >> REDO: >> >> >Aborted >> >> This means recover_cancel or ctrl-c was detected. >> >> And you see the next lines: >> >> >> >2004-06-16 13:42:15 2412 ERR 52608 RESTART >> LOCAL: >> >> >failed >> >> >2004-06-16 13:42:15 2412 ERR 63 Log >> >> RESTART >> >> >ERROR '400' => SHUTDOWN IS FORCED >> >> >2004-06-16 13:42:15 2412 12696 DBSTATE >> Change >> >> >DbState to 'SHUTDOWN'(24) >> >> I can only repeat me. The lines above are telling >> you the consequence >> of the detected abortion request. There was no other >> error detected. >> >> The _reason_ why the restart forces a shutdown is >> given >> by the number 400 which means e_cancelled (ggg00). >> >> By the way, there was a savepoint triggered at the >> end. Relating your first question of this thread. So >> the state of the log recovery of the standby system >> is saved before it is aborted. >> And you should not need to begin the log recovery >> with the already recovered log backups. >> >> regards, >> Uwe >> >> >-----Original Message----- >> >From: Alexei Novakov >> [mailto:[EMAIL PROTECTED] >> >Sent: Sunday, June 20, 2004 10:44 PM >> >To: Hahn, Uwe; MaxDB mailing list. >> >Subject: RE: SAPDB Standby database setup. >> > >> > >> >But is there any way to figure out the real reason >> for >> >the failure? >> > >> >--- "Hahn, Uwe" <[EMAIL PROTECTED]> wrote: >> >> I think this is a problem of labeling. >> >> >> >> The log recovery is a kind of a restart which log >> >> source is a log backup instead of the log volume. >> >> From the point of view of the restart the restart >> >> failed - because it was cancelled ('400'). I will >> >> think about it to avoid these confusing messages >> >> which only want to tell that the restart (log >> >> recovery) was aborted and not that an error was >> >> detected. >> >> >> >> regards, >> >> Uwe >> >> >> >> >-----Original Message----- >> >> >From: Alexei Novakov >> >> [mailto:[EMAIL PROTECTED] >> >> >Sent: Friday, June 18, 2004 8:35 PM >> >> >To: Hahn, Uwe; MaxDB mailing list. >> >> >Subject: RE: SAPDB Standby database setup. >> >> > >> >> > >> >> >Yes, here is the end of knldiag file: >> >> > >> >> >2004-06-16 13:42:06 2634 11565 startup >> DEVi >> >> >started >> >> >2004-06-16 13:42:06 2454 52101 RESTORE >> >> Filetype: >> >> >file >> >> >2004-06-16 13:42:06 2452 46 Log >> >> >recovering log from tape from IOSeq 0 (MaxIOSeq >> >> from >> >> >tape: -1) >> >> >2004-06-16 13:42:06 2453 11000 vasynclo >> >> >> >>>'/opt/project/var/database/backup/TEST1/log.backup.001' >> >> >devno 84 T78 >> >> >2004-06-16 13:42:06 2375 12822 TASKING >> Thread >> >> >2634 joining >> >> >2004-06-16 13:42:06 2453 52024 RESTORE 56 >> >> pages >> >> ><- "ackup/TEST1/log.backup.001" >> >> >2004-06-16 13:42:06 2454 52012 RESTORE new >> >> tape >> >> >required 4300 >> >> >2004-06-16 13:42:06 2634 11566 stop >> DEVi >> >> >stopped >> >> >2004-06-16 13:42:14 2452 31 Log >> normal >> >> >end of log found at off -1 lastseq 1598. >> >> >2004-06-16 13:42:14 2452 49 Log >> >> >> >>>last-redo-read#3622:TR2363(1)[EMAIL PROTECTED]'Commit':20040616:14606 >> >> >2004-06-16 13:42:14 2452 WNG 18 Log >> REDO: >> >> >Aborted >> >> >2004-06-16 13:42:14 2412 44 Log >> >> Savepoint >> >> >requested by T37 reason 'Distance' (started). >> >> >2004-06-16 13:42:14 2422 4 Pager >> SVP(1) >> >> >Start Write Data >> >> >2004-06-16 13:42:14 2422 5 Pager >> SVP(1) >> >> >Stop Data IO, Pages: 7 IO: 6 >> >> >2004-06-16 13:42:14 2422 6 Pager >> SVP(2) >> >> >Wait for last split, TaskId: 47 >> >> >2004-06-16 13:42:14 2422 7 Pager >> SVP(2) >> >> >Stop Wait for last split, Pages: 0 IO: 0 >> >> >2004-06-16 13:42:14 2422 53070 SAVPOINT >> >> >B20PREPARE_SVP: 6 >> >> >2004-06-16 13:42:14 2422 8 Pager >> SVP(3) >> >> >Start Write Data >> >> >2004-06-16 13:42:15 2422 9 Pager >> SVP(3) >> >> >Stop Data IO, Pages: 1 IO: 1 >> >> >2004-06-16 13:42:15 2422 10 Pager >> SVP(3) >> >> >Start Write Converter >> >> >2004-06-16 13:42:15 2422 11 Pager >> SVP(3) >> >> >Stop Converter IO, Pages: 8 IO: 8 >> >> >2004-06-16 13:42:15 2422 53071 SAVPOINT >> >> >B20SVP_COMPLETED: 6 >> >> >2004-06-16 13:42:15 2412 ERR 52608 RESTART >> LOCAL: >> >> >failed >> >> >2004-06-16 13:42:15 2412 ERR 63 Log >> >> RESTART >> >> >ERROR '400' => SHUTDOWN IS FORCED >> >> >2004-06-16 13:42:15 2412 12696 DBSTATE >> Change >> >> >DbState to 'SHUTDOWN'(24) >> >> >--------------------------------------- current >> >> write >> >> >position ----------------- >> >> > >> >> >> >> >> > >> >> >+++++++++++++++++++++++++++++++++++++++ Kernel >> Exit >> >> >++++++++++++++++++++++++++++ >> >> >2004-06-16 13:42:15 0 12845 DBSTATE >> Kernel >> >> >exited normal >> >> >2004-06-16 13:42:15 0 12890 DIAGHIST >> Backup >> >> of >> >> >diagnostic files will be forced at next restart >> >> >2004-06-16 13:42:15 0 12808 DBSTATE >> >> Flushing >> >> >knltrace pages >> >> >2004-06-16 13:42:15 0 11560 COMMUNIC >> >> Releasing >> >> > T79 >> >> >2004-06-16 13:42:15 0 12696 DBSTATE >> Change >> >> >DbState to 'OFFLINE '(28) >> >> >--------------------------------------- current >> >> write >> >> >position ----------------- >> >> >> >> >> > >> >> > >> >> >It is clear that recovery was successful, but it >> is >> >> >not clear to me what caused error and restart. >> >> > >> >> >Alexei. >> >> > >> >> >--- "Hahn, Uwe" <[EMAIL PROTECTED]> wrote: >> >> >> Ok, 7.4.3.32 writes a savepoint if restore log >> is >> >> >> cancelled. >> >> >> If any error occurs during log redo and cancel >> is >> >=== message truncated === > > > > >__________________________________ >Do you Yahoo!? >New and Improved Yahoo! Mail - Send 10MB messages! >http://promotions.yahoo.com/new_mail > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
