Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
Exchange Server's transaction logs are in some ways just as important as the main data store. Without them, it's impossible to recover a database completely if there's a failure.
WIth a Microsoft Exchange backup, you can restore to the point the backup was made, but not beyond that. Only log files can help you step forward from the backup to just before the actual failure. So you need to structure your Exchange server so that log files are protected independently of the data store.
The most common way to do this is to place the log files on a completely different physical disk than the Exchange information store, preferably one that's mirrored.
If you're building a dedicated Exchange server, it makes sense to set aside an extra pair of disks for the sake of the transaction logs. The initial expense will more than pay itself back if either the data store or the transaction logs become corrupted.
Since multiple storage groups use a common set of logs in Exchange 2003, you'll need to plan the size of the transaction log disks around that -- based on how often you back up and how much data flows through Exchange, since transaction logs are deleted whenever the database is backed up.
Putting transaction logs on a separate physical drive is also a performance-enhancer, but it should not be the primary reason for doing this. Transaction logs are almost never read back, unless you're replaying actions for the sake of a backup. So performance gain is not even really the issue.
It may take longer to write data to a mirrored pair of disks, but at this point in time, the performance hit from using mirrored disks is negligible -- especially compared to the performance hit that'll come with losing the log entirely!
The only time performance really becomes an issue is when the server is placed under a very heavy load, at which point it's probably time to look at an upgrade or splitting the load across more than one server. Using a decent hardware RAID controller and 10K RPM drives should negate any noticeable performance issues you'd have.
Warning: Backing up the information store to the same drive that holds the transaction logs, for the sake of convenience, is never a good idea, even if the transaction log drives are redundant (i.e., RAID 1). On the off chance that both drives fail -- and it does happen -- you've lost your transaction logs and the backups that would be used in conjunction with them. Keep your logs and the information store as redundant and segregated as possible under all circumstances.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Tip: Backing up, truncating and cleaning up transaction logs
Best Practices Checklist: Exchange Server disaster recovery planning
Reference Center: Information store tips and resources
Reference Center: Exchange backup and recovery
