Hi John, if you'v lost your data and have to recover a databackup, this is marked with a specific kind of timestamp (called LogIOSequenceNumber). If this can be found on the still intact LogVolume, then a simple restart will bring you back all changes made since the backup-time. If it cannot be found on the LogVolume, you will get an error-message and will be unable to restart. Instead you has to fill the gap of LogEntries from the backup-time until the oldest LogEntry on the LogVolume. If LogAutoOverwrite is enabled, it is impossible to do log-backups and therefore you cannot fill this gap. Your only choice is to clear the LogVolume and restart with all changes lost. So it's generally no good idea to use the autooverwrite-mode.
kind regards, Martin > -----Urspr�ngliche Nachricht----- > Von: John L. Singleton [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 15. April 2004 20:46 > An: Strahl, Torsten > Cc: Open Source List > Betreff: Re: Logging Non sequitur > > > Hi there Torsten, > > Thanks for the response! I found it very helpful. > > In response to answer #1: > > Ah, I see. I guess I hadn't considered that in Auto Overwrite mode it > would be able to reliably restore up the the last savepoint. > > I had imagined a situation like this: > > t=0 > --------S1----------------S2--------------Sn-----------t=C-1---(lots > of transactions & savepoints)---t=C------------------> > Wherein, at the various timepoints: > > t=0 : I just got a fancy new job as a MaxDB DBA. I like my > new job, so I do a full data backup. > 0 <= t < X: I'm a lazy system administrator, so I neglect to > do another > data backup between t=0 and t=X. > S1,S2,Sn...: Savepoints > t=C : The Big Crash > t=C-1 : The Night Before the Big Crash > > Now, say at C-1, the night before the big crash, I get > slashdotted, and > the slashdotters buy a hundred million nerf guns from my > online store. > In the process, someone breaks into my database server, and > deletes my > data volumes. > > Let's say that from (C-1) to (C) is enough log entries to cause a > complete re-write of my log area, up to the last SAVEPOINT > Sl. As such, > pretend that I now have Redo Log Entries for Transactions 99, > 000, 000 - > 100,000,000. But Not for 1-98,999,999. > > > When Logs are in NORMAL/Automatic Backup mode, this sort of situation > wouldn't be a problem, as I would have all of the backups, > right up to > t=C. Even if my data backup is very old (as in my example) we > could read > from my log backups and log area. Then the Redo Entries would be put > into the Redo List and the database would be up to date. > > But when I was trying to figure out whether or not Auto > Overwrite logs > would use their Redo Entries to bring the data volumes up to date, > because of the example I gave, I assumed no. Therefore, I > also assumed > that mirroring was extra overhead. > > How would they behave in this case? Would the Log Reader be able to > distinguish between an impossible restore situation, and one that is > possible? (For example, a minor lapse in operations, for > which all log > entries are available.) Obviously restoring from what's in > the log area > wouldn't make sense---what if between t=0 and t=C-1, I changed the > database structure? This information would be lost. > > Sorry to give such a crazy example. > > I hope you agree to me that there are no oddities:) > > > > Nope :) What oddities? I don't know of any oddities here... > > > > All Best, > JLS > > Strahl, Torsten wrote: > > >Hi John, > > > >Question 1: > >A mirrored log area is always a good thing, because it gives > you more safeness, > >if one of your log volumes has a problem. If your log area > isn't mirrored and one > >of your log volumes has a problem you lose all the actions > made after the last > >SAVEPOINT, including transactions which has finished > successfully with a commit > >statement. Note that the database is still consistent, > because the undo information > >is part of the data area not of the log area! > >If your log is mirrored you could restore the redo log from > the intact log volume > >and you will be able to "redo" the committed transactions, > so you have NO loss of data. > > > >If you use the log overwrite feature the above mentioned > statements are still valid, > >because the same scenario could happen. The overwrite > feature "only" means that your > >log history is interrupted and you will not be able to > recovery your database like this: > > > >1) recover data > >2) recover pages > >3) recover log1 <============== not possible, because > no log backups available > >4) recover log2 <============== not possible, because > no log backups available > >5) read the last log from the log area <== as a rule the log > do not fit to the restored data > > > >If a mirrored log is configured MaxDB writes the redo log > always simultaneous to both > >log volumes, independent of the overwrite mode. This is no > overhead! Both log volumes > >will be overwritten, if the log cycle is closed. > > > >Question 2: > >I don't know the recover_volume command, but it looks like > the old 7.3 syntax for devspace recovery (SystemDev -> > mirrrored Systemdev or LogDev -> mirrored LogDev). I will ask the > >responsible developer? > > > >In 7.4.3.X you have two commands to restore mirrored log volumes: > > > > 1) Is there a corrupted log volume and what is the name? > > > > dbmcli -d ... -u ... util_execute get bad log volume > > if so the name of the corrupted log volume is > returned for example 'myBadVolumeName' > > > > 2) Copy the intact log volume to the corrupted log volume > > > > dbmcli -d ... -u ... util_execute restore log volume > 'myBadVolumeName' > > the given bad log volume name 'myBadVolumeName' is the > result of the first command. > > > > > >Note that this will work only if you have a mirrored log! > >I hope you agree to me that there are no oddities:) > > > >Regards, > >Torsten > > > >SAP DB, SAP Labs Berlin > > > >BTW: > >Take a look at http://www.sapdb.org/7.4/pdf/logsettings_eng.pdf > > > > > >-----Original Message----- > >From: John L. Singleton [mailto:[EMAIL PROTECTED] > >Sent: Donnerstag, 15. April 2004 16:32 > >To: '[EMAIL PROTECTED]' > >Subject: Logging Non sequitur > > > > > >Hello all, > > > >I'm trying to come up with a sort of matrix of the various logging > >settings and I've come across a few oddities: > > > >for example: > > > >1) Does it make sense to use Mirrored Log Volumes *with* > Overwrite = ON? > > > >It is certainly possible to do this, but I'm afraid it just > seems like > >extra overhead to me. Is this the case? How does MaxDB > behave in this > >case? Does it continue to write to both, and then overwrite the > >information in both? > > > >2) You can recover a damaged LOG volume with > recover_volume, but can > >you use recover_volume to recover a damaged mirror volume? > Apparently > >you can recover the mirror volume with commands like: > > > >util_execute RESTORE LOG VOLUME 'LOG_M_001' > > > >But recover_volume only seems to work when restoring /from/ > the mirrored > >copy. > > > > > >Any thoughts? > > > >Cheers, > >JLS > > > > > > > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: > http://lists.mysql.com/maxdb?> [EMAIL PROTECTED] > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
