Hi Martin, I changed the LOG_SEGMENT_SIZE to be 1/3 of the total logarea size (logarea = 3 logfiles of 5MB) . I redid the entire process of recovery;
first without copying the logfiles: no data was in the backup instance second time with copying the logfiles: this time the database did start. (al other times it failed with an emergency shutdown) 90% of data is now actually available in the backup instance. The latest records are missing. When looking at the knldiag: "WNG Converte Restart aborted because of DB Full detection." almost completely fills the knldiag file. However the datafile is only full for about 28% . Is it possible that the data area ran full during recovery? Is that what it means? Is it also possible that the remaining 10% of data was still in the log cache of the main instance and not yet written to the logfile by the logwriter? It seems quite alot to be in cache; loginformation for about 10000 rows. Another question related. I use 3 logfiles because I thaught maxdb used them in a cyclic way like oracle does. But after rereading the documentation I not sure anymore if it works this way. Are the 3 logfile seen as one log area then? What advantage can there be of using 3 separate file? Is the logarea locked when a logbackup is written? Regards, Filip PS Happy there is already some progress :) On Mon, 2004-07-12 at 15:44, Brunzema, Martin wrote: > > > > -----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] > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* * System Engineer, Verzekeringen NV * * www.verzekeringen.be * * Oostkaai 23 B-2170 Merksem * * 03/6416673 - 0477/340942 * *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
