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]
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
