Hi Martin, It works !! I have managed to do a complete recovery with copying the logfiles up to the last transaction. I have increased the dataspace. Is there a rule of thumb to determine the datafile size that is needed for a recovery based on the amount of _used_ dataspace in a working instance?. I now just doubled it because it is a small testdatabase, but for a production database of 400GB, that would mean a lot more disks...
Thank you so far! I will also reduce the LOG_SEGMENT_SIZE again and see if I can reproduce the emergency shutdown on db_online. Regards, Filip On Tue, 2004-07-13 at 11:04, Brunzema, Martin wrote: > Hi Filip, > > > -----Urspr�ngliche Nachricht----- > > Von: Filip Sergeys [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 13. Juli 2004 10:27 > > An: Brunzema, Martin > > Cc: [EMAIL PROTECTED] > > Betreff: Re: AW: database recovery question > > > > > > 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) > can you remember the reason for the 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? > Yes. During Redo/Recovery the Information about the Redo > is copied into the datacolumes (because we need temporary > storage for synchronizing the redo-tasks properly). Increase > the size of your database. > > > > > 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. > There is _NO_ logcache. If you issue a commit and get the return > from this command, then the commit is written onto the logvolume. > > > > > > > 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? > The 3 logfiles are seen as one area, which is written cyclic. > There is no advantage in using more than one logvolume other than > to correct a bad configuration by adding a logvolume. > The logarea is not locked during logbackup. But of course it s not > allowed to reuse logpages, which had not been saved before. > > -- > 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]
