Defragmentation is undertaken by Microsoft Exchange at regular intervals (by default between 1am and 4am) across all mail stores. This can result in a significant increase in disk activity on the database, accompanied by the generation of log files. The effect can be more pronounced when there are mailbox storage policies imposed, as these result in CPU-intensive activity and more space being freed during the defragmentation process. As a consequence of the increase in replication traffic, performance problems may arise in some - most notably WAN - implementations.
While the information in this Knowledgbase article addresses Exchange-specific issues, the recommendations are valid for SQL Server databases under the following conditions:
1) Custom database application housekeeping processes: Applications may perform order reconciliation, batch processing, and so forth; and if these result in large scale changes to the database, replication traffic may increase.
2) SQL server index defragmentation: While performed less frequently than its Exchange counterpart, it too can present a drain on resources.
In some situations, updates can accumulate in the active server's unsafe queue. This backlog can in turn impact application performance, in which case Exchange or SQL Server clients may experience poor response times as the application slows down. This may happen:
- If the rate at which data is generated on the active server exceeds the available bandwidth, as may occur for a WAN deployment with insufficient bandwidth to handle the peak load
- If the rate at which data is generated on the active server exceeds the rate at which the passive server can apply the changes. This might occur on a system with faster disks on the Active server than the Passive server - for example, where the active server is using a SAN, and the passive server is using a slower RAID controller.
These situations can be managed by adjusting the maintenance schedule such that the effect of any backlog is minimized and constrained to the off-peak hours. Neverfail Heartbeat handles large spikes in processing load during peak hours. When there are also sustained high loads due to maintenance activity, some schedule adjustment may be required to ensure the backlog has cleared before the core hours begin.
1) Use SCOPE to record data over a 24-hour period. On the 'Channel' tab of the file nffsidc.xls, generated by Neverfail Group from your SCOPE data, enter your actual channel bandwidth. This should allow you to predict the approximate size of any backlog, and the time required to process and clear the backlog.
2) Adjust the maintenance period according to findings in 1), so the backlog has time to clear before the office core hours.
3) Ensure that the maintenance period does not coincide with the backup schedule.
4) Avoid performing a Full System Check on the protected file system during Exchange maintenance period. A saturated channel can occur when the following two conditions are met:
a) Full System Check results in large amounts of data being synchronized with the passive server.
b) Data is generated due to mailbox defragmentation.
5) If steps 1-4 do not resolve the issue, try setting different start times on the schedule for each mailbox level. This may be particularly useful in environments where there are multiple, large mail stores.
If the backlog can not be handled in off-peak hours then the root cause of the bottleneck needs to established, and addressed. In cases where additional bandwidth cannot be acquired, or disk bottlenecks cannot be resolved, a solution may be to schedule the maintenance tasks solely at the weekend. While this will result in more replication traffic, this traffic can be managed over a time frame of two days.
The schedule can be changed in Exchange System Manager on the database tab associated with a public or private database store. This setting can also be applied using a Mailbox store policy within the organization.