Chat now with support
Chat with Support

Migration Manager for Email Archives 9.6 - SQL Guide

Memory Considerations

The recommended memory should be available at each SQL Server instance to ensure the data manipulation does not cause excessive paging to disk both in the Migration Manager for Email Archives databases and tempdb, which will quickly degrade performance.

Install the appropriate edition of Windows Server and SQL Server to support the capacity of memory that is installed. See the Migration Manager for Email Archives compatibility charts for supported versions of SQL Server.

Under normal circumstances, SQL Server should be allowed to manage memory dynamically. It may be necessary to change the SQL Server minimum and maximum memory to ensure the memory is used appropriately between SQL Server instances, Reporting services or other co-located services.

Network Considerations

We recommend that you connect the Migration Manager for Email Archives SQL servers and Migration Manager for Email Archives servers via gigabit network technology. The SQL servers may require multiple network interface cards to support the anticipated loads.

We also recommend that you disable the TCP Chimney Offload, TCP/IP Offload Engine (TOE) or TCP Segmentation Offload (TSO) to prevent network issues. For guidance in disabling these, see the Symantec technical article TECH55653.

Network

100 MBit

Network

1 GBit

Storage Considerations

It is vital to ensure the storage does not become a bottleneck. By following Microsoft SQL Server best practices, it can be ensured that the SQL server is suitably sized. Avoid using network-based storage for the database files.

In most cases, RAID-based storage will be needed to achieve the storage requirements. To maintain performance and reliability, consider hardware-based RAID rather than software-based RAID. To achieve redundancy on striped arrays while maintaining performance, consider the RAID scheme carefully.

RAID levels 5 and 6 are popular, cost-effective methods of achieving redundancy while maintaining striped disk read performance. However, writing incurs a cost of four to six physical operations per write. A poorly sized RAID-5 or 6 implementation can significantly reduce the performance of write-intensive activity. Correctly sizing a RAID-5 or 6 implementation to maintain write performance may become more costly than RAID-1+0, and therefore a RAID-1+0 scheme should be considered.

NOTE: Consider a RAID 1+0 scheme for maximum performance.

In the case of local or direct attached storage, use multiple controllers supporting multiple channels to distribute the load between the multiple storage locations and provide sufficient throughput. The controllers should also provide a battery-backed read and write cache to aid performance. A minimum of 512 MB controller cache is recommended for local or direct attached storage.

Before using partitions on a storage area network (SAN), consider the I/O load together with any other applications that are already using the SAN to ensure that the performance can be maintained. Ideally, discuss the implementation with the SAN hardware vendor to ensure that it can achieve optimum performance. Typically, LUNs should be created across as many suitable disks as possible, using entire disks rather than partial disks to prevent multiple I/O-intensive applications from using the same disks. When the HBA is configured on the host, ensure that the Queue Depth is set to an optimal value. This should be discussed with the storage vendor.

NOTE: Be wary of using partitions on SANs without discussing requirements with the appropriate storage vendor.

When creating a basic NTFS volume on a storage device, it is very important to align the volume with the device sector or stripe unit boundaries to prevent unnecessary disk operations that can significantly impact performance. (Dynamic volumes cannot be aligned at time of publication). See the TechNet article “SQL Server best practices” for more information and using the diskpart tool to create and align volumes. This article also recommends that both log and data partitions are formatted with 64 KB allocation unit sizes.

In most cases, you should create a single volume on each disk array to avoid contention at the disks between the partitions.

Each database requires the disks to be arranged for two different purposes; the database data files and the transaction log files. The data files require good random access, and therefore a striped array of many disks should be used. The log files require good sequential write performance, so each log file should be placed on its own high-speed array with good transfer rates.

NOTE: To achieve redundancy on the sequential write-intensive disks (log), use a RAID-1 or RAID-1+0 scheme with high-speed, 15k rpm disks.

Arrange the SQL server storage to accommodate the different types of data, distributing the load as appropriate. The following arrangements of storage might be considered for each data requirement:

System drive

RAID-1 array

Tempdb log file

RAID-1 or 1+0 array

Tempdb data files

RAID-1 or 1+0 array

Migration Manager for Email Archives Directory data file

Migration Manager for Email Archives Directory log file

Each link Database data file

Each link Database log file

If multiple database files are located on one partition, it may require regular file defragmentation to maintain performance.

Types of Storage Device

It is vital to ensure the storage does not become a bottleneck. By following Microsoft SQL Server best practices, it can be ensured that the SQL server is suitably sized. Avoid using network-based storage for the database files.

In most cases, RAID-based storage will be needed to achieve the storage requirements. To maintain performance and reliability, consider hardware-based RAID rather than software-based RAID. To achieve redundancy on striped arrays while maintaining performance, consider the RAID scheme carefully.

RAID levels 5 and 6 are popular, cost-effective methods of achieving redundancy while maintaining striped disk read performance. However, writing incurs a cost of four to six physical operations per write. A poorly sized RAID-5 or 6 implementation can significantly reduce the performance of write-intensive activity. Correctly sizing a RAID-5 or 6 implementation to maintain write performance may become more costly than RAID-1+0, and therefore a RAID-1+0 scheme should be considered.

NOTE: Consider a RAID 1+0 scheme for maximum performance.

In the case of local or direct attached storage, use multiple controllers supporting multiple channels to distribute the load between the multiple storage locations and provide sufficient throughput. The controllers should also provide a battery-backed read and write cache to aid performance. A minimum of 512 MB controller cache is recommended for local or direct attached storage.

Before using partitions on a storage area network (SAN), consider the I/O load together with any other applications that are already using the SAN to ensure that the performance can be maintained. Ideally, discuss the implementation with the SAN hardware vendor to ensure that it can achieve optimum performance. Typically, LUNs should be created across as many suitable disks as possible, using entire disks rather than partial disks to prevent multiple I/O-intensive applications from using the same disks. When the HBA is configured on the host, ensure that the Queue Depth is set to an optimal value. This should be discussed with the storage vendor.

NOTE: Be wary of using partitions on SANs without discussing requirements with the appropriate storage vendor.

When creating a basic NTFS volume on a storage device, it is very important to align the volume with the device sector or stripe unit boundaries to prevent unnecessary disk operations that can significantly impact performance. (Dynamic volumes cannot be aligned at time of publication). See the TechNet article “SQL Server best practices” for more information and using the diskpart tool to create and align volumes. This article also recommends that both log and data partitions are formatted with 64 KB allocation unit sizes.

In most cases, you should create a single volume on each disk array to avoid contention at the disks between the partitions.

Each database requires the disks to be arranged for two different purposes; the database data files and the transaction log files. The data files require good random access, and therefore a striped array of many disks should be used. The log files require good sequential write performance, so each log file should be placed on its own high-speed array with good transfer rates.

NOTE: To achieve redundancy on the sequential write-intensive disks (log), use a RAID-1 or RAID-1+0 scheme with high-speed, 15k rpm disks.

Arrange the SQL server storage to accommodate the different types of data, distributing the load as appropriate. The following arrangements of storage might be considered for each data requirement:

System drive

RAID-1 array

Tempdb log file

RAID-1 or 1+0 array

Tempdb data files

RAID-1 or 1+0 array

Migration Manager for Email Archives Directory data file

Migration Manager for Email Archives Directory log file

Each link Database data file

Each link Database log file

If multiple database files are located on one partition, it may require regular file defragmentation to maintain performance.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating