> -----Urspr�ngliche Nachricht----- > Von: Filip Sergeys [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 12. Juli 2004 14:11 > An: Brunzema, Martin > Cc: [EMAIL PROTECTED] > Betreff: Re: AW: database recovery question > > > Hello Martin, > > > On Mon, 2004-07-12 at 11:39, Brunzema, Martin wrote: > > Hi Fillip, > > > > > -----Urspr�ngliche Nachricht----- > > > Von: Filip Sergeys [mailto:[EMAIL PROTECTED] > > > Gesendet: Montag, 12. Juli 2004 09:13 > > > An: [EMAIL PROTECTED] > > > Betreff: database recovery question > > > > > > > > > Hello, > > > > > > I'am testing the database recovery capabilities of Maxdb. > > > I use the example in the > > > documentation.(http://dev.mysql.com/doc/maxdb/en/cd/0bbc023569 > > > f4428f571bae780e3ebc/content.htm) > > > , but I can't recovery any data. > > > > > > This is the scenario: > > > 1)Create two identical databases. One as a active instance, > > > the other as > > > a standby database. (I use the DBMGUI for that purpose) > > > > > > 2)Create a complete backup and a log backup medium > > > > > > 3)In the active db, I created 2 simple tables > > > > > > 4)Make a complete backup > > > > > > 5)Activate automatic log backup > > > > > > 6)Fill the two tables with 100000 records (a simple dbproc > > > with a loop) > > > > > > 7)During the table filling 15 automatic log backups where created. > > > > > > 8)Simulate a server crash by killing the db processes > > > > > > 9)Copy all backups to a place where standby database can > access them > > > > > > ->Login in the standby database and import the log backups > > > > > > 10)dbmcli -d db2 -u <user>,<passwd> > > > 11)util_connect > > > 12)db_activate RECOVER FULL -> returncode 0 OK > > > 13)recover_start ARCH LOG 001 -> returncode -7075 > > > 14)recover_start ARCH LOG 002 -> returncode -8020 (next file) > > > 15)recover_replace ARCH /var/maxdb/test/db2/logs/arch.003 > > > 16)repeate this command up to arch.015 > > > 17)recover_ignore (to bring the db online) > > > 18)util_release > > > > > > 19)select * from table1 -> EMPTY !! (idem for table2) > > > Thus tables where created OK as part of the fullbackup, but > > > there is no > > > data in them from the log backups. > > > > May it be possible, that you did not issue a COMMIT during > > your filling of the database? If so, the transaction will > > just be rollbacked when you execute the recover_ignore. > > > Add first I thought of that to, so I made sure there was a commit. > This is the database prcocedure loop: > create dbproc FILL (in loop fixed(6)) as > while loop <> 0 do begin > loop = loop -1; > insert into test.table1 values (test.seq1.nextval, > test.seq2.nextval, date, time, stamp); > insert into test.table2 values (test.seq1.currval, > test.seq3.nextval, date, time, stamp); > end; > > commit is not allowed in a dbproc apparently. So I executed it in SQL > studio with autocommit on, type committed and I executed it like this > call FILL(10000) > // > commit > > I hope this commits the transaction.
Hi Filip, yes, this commits your transaction. But this commit is the last logentry written on the LogVolume. Using autosave-log up to one third of the LogVolumeSize may be unsaved (if you use the default for LOG_SEGMENT_SIZE). Even if you save your Log manually, the last written page is still in access by the Logwriter an thus cannot be saved (this changed in Rel 7.5.00 Build 8, with this Build also the youngest LogPage may be saved). So I assume, that your commit is not saved in your Logbackups. If you want to check this prior to Rel 7.5.00B08, save your log in admin-mode. Then everything is saved. > > This time I created the tables after a complete backup. Thus the table > create statements are part of the logbackup. They seem to be created. > The sequences that are used in the dbproc do not however reflect their > most current state. So the create of the tables and the first inserts in the table are in the Logbackup, the last ones not. > > First of all: Prefer the backup/recovery-mechanism of the MaxDB. > > Otherwise no one can assure a proper (i.e. consistent) state of the > > database. > Copying the logfiles seems to be a maxdb supported mechanism > http://dev.mysql.com/doc/maxdb/en/72/7fbb19e4395c4a82d92c23f4b4d32b/content.htm If it is possible, I would prefer to use database-mechanisms for this. Also there had been a bug, which prevents a restart after the copying of a LogVolume (See http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1129184) > > Have a look into knldiag by your own. I assume that you should find > > there some information that data and log are not compatible. > I have now done that, but there is no apparent signs of failed log reads > or db full or anything. Anything particular I should be looking for? If its the above mentioned error, then you should find the message "savepoint not found on log" in the file knldiag. regards, Martin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
