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/[EMAIL PROTECTED]
