Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: AW: AW: database recovery question
From: Filip Sergeys (filip.sergeysverzekeringen.be)
Date: Tue Jul 13 2004 - 05:05:28 CDT
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.
On Tue, 2004-07-13 at 11:04, Brunzema, Martin wrote:
> Hi Filip,
> > -----Ursprüngliche Nachricht-----
> > Von: Filip Sergeys [mailto:filip.sergeysverzekeringen.be]
> > Gesendet: Dienstag, 13. Juli 2004 10:27
> > An: Brunzema, Martin
> > Cc: maxdblists.mysql.com
> > 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/maxdb?unsub=filip.sergeysverzekeringen.be
* 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