An additional consideration for Exchange log file drive sizing…

  • Article

When planning an Exchange 2007 installation storage considerations are a very important factor.  I wanted to call attention to a sizing consideration that may not be accounted for in other places.  This sizing consideration should be accounted for when planning an environment that may use Cluster Continuous Replication, Local Continuous Replication, or Standby Continuous Replication.

When planning your log file drive sizing it is important to consider when log files are actually purged.  It is important to remember that log file purging cannot occur unless:

  • CCR – The log has been copied, inspected, and replayed.
  • LCR – The log has been copied, inspected, and replayed.
  • SCR – The log has been copied, inspected, and put out for replay at a later time.

When the above criteria cannot be met log files will continue to fill the log file volume even if a backup is performed successfully.  If the criteria above are not met, and a backup is performed successfully, logs will not be truncated.

Depending on the number of days that the replication partner is not available, this may result in a large number of log files remaining on the log file drive and in some instances a log file drive full condition results.  When the log file drive is full and logs can no longer be created, the database instance(s) will dismount and be unavailable.

This would require the administrator to either return the log copy target to availability so that logs can be copied and purged or to purge log files manually.  In the event log files are purged manually a full database re-seed of the passive target would be necessary.

In planning you should consider factors that might cause nodes to be unavailable for an extended period of time – for example WAN issues.  If necessary increase the size of your log file volume to accommodate for periods where replication cannot occur.  For example, if your log generation per day is estimated at 2000 logs, and you estimate that any outage of a node or network etc could last up to 5 days, you need to make plans to accommodate up to 5 days of non-replicated log files.

The storage calculator can assist you in your planning.  There are two areas of the storage calculator that help you take into account planned outages of both replication and backups in order to provide a more accurate log file drive sizing.  The two areas of the storage calculator that can help you better estimate log file volume size for backup and network issues are:

  • In Step 3 – Backup Configuration – Backup Failure Tolerance
    • The backup failure tolerance allows you to choose how many days you can go without a backup that performs truncation.  Full Backups and Incremental backups purge the transaction log files since the last full / incremental backup.  However if a backup job fails you need to ensure that you have enough capacity to allow for either restoration or continuation of service until the next backup window.

image 

  • In Step 4 – Storage Requirements Input Factors – Log Replication Configuration – Network Fault Tolerance (Days)
    • When deploying geographically dispersed CCR and SCR across a WAN link there is the possibility that the network link between the two locations will become unavailable.  As a result, truncation on the source cannot occur.  To ensure you have enough space to survive the network outage, enter a value for Network Fault Tolerance (measured in days).

image

Download the storage calculator here -

https://msexchangeteam.com/files/12/attachments/entry438481.aspx

Read about the storage calculator here -

https://msexchangeteam.com/archive/2007/01/15/432207.aspx

By planning for lack of replication ahead of time you can hopefully ward off any out of disk space conditions or conditions that may cause a full re-seed to become necessary.