Database Transaction Logging

[Guest]

Actually that is not true. Just because you have a 24 MB video clip doesn't mean you will have 24 Mb of log files generated. That information is incorrect.

Maybe you should research these things before making incorrect statements.

[quote="support"]Exchange Transaction logs often actually grow faster and consume disk space faster than the database files themselves. Every transaction generates a log entry. For example, if you send a message containing a 24MB video clip to your inbox, then delete the message, you'll have generated more than 24MB of log files: one set of log data records the new message, while a separate set records its deletion.

The biggest stumbling block to successful Exchange recovery is circular logging; when you enable it, you're giving Exchange permission to throw away log data. With circular logging off, as long as you have a good copy of your transaction logs, you can restore your database to a consistent and correct state. If being able to recover your data is more important than the cost of having to buy enough disk space, turn circular logging off on your IS servers.

Even if you lose the entire public or private IS--say the single disk it's on crashes beyond repair--you may still be able to restore the server with no data loss. For this to happen, there are two ironclad requirements:

You must have a complete backup: either a full backup or a full backup combined with appropriate incremental and differential backups. If you use differential backups, all the differential tapes must be available and complete.

Circular logging must be turned off, and you must have access to the log files either on their original disk or from a recent backup. Exchange 5.5 turns circular logging on by default, so you must manually turn it off.

As long as you meet these requirements, data loss can be zero. If Exchange is updating a table in the private IS and suddenly gets inturrupted, the IS ends up corrupted. Upon reboot, the IS service fails to start. A review the event log determines that the IS won't start because the database is corrupted.

If the drive with your IS had failed, or if you had to repair some other component, you'd still be able to restore things the same way. Even if you have to rebuild a server from scratch, as long as you have good backups, you'll be able to make things right. Note that this recovery wouldn't have been possible without proper planning and execution, and time was still required time for the recovery itself.

Depending on what caused the original corruption, it's conceivable that replaying the logs will lead to the identical circumstances and again corrupt the store. Be sure to pin down the cause of failure before you try to recover from it.[/quote]