Chat now with support
サポートとのチャット

Migration Manager for Email Archives 9.7 - SQL Guide

Requirements Overview

To best support your SQL server and the needs of a migration, it's recommended that all production Migration Manager for Email Archives deployments run on a dedicated instance of Microsoft SQL Server.

Migration Manager for Email Archives is a feature-rich product and can therefore result in very diverse SQL Server load profiles between customer deployments. As Migration Manager for Email Archives scales, additional databases and the associated increase in load will require scaling of the SQL Servers to meet the load.

Although Enterprise Edition of Microsoft SQL Server is recommended, Standard Edition may be used if the SQL instance uses the recommended (not minimum) resources associated with the size of migration you are performing. Planning for additional time will be required to accommodate regularly required offline maintenance.

It may be necessary to separate out specific Migration Manager for Email Archives databases such as the Directory and Link databases to dedicated SQL Servers.

There are many factors which may influence the deployment, but an initial server sizing guideline would be to provision the CPU cores and RAM described in the information below arranged in as many servers as desired, evenly distributing the Migration Manager for Email Archives databases if deployed as multiple SQL servers.

Hardware Considerations

Migration Manager for Email Archives requires a number of SQL databases:

The SQL Server that manages these databases must reside on a separate server than the Migration Manager for Email Archives core and modules. The only exception is for a non-production pilot/demonstration system.

The table below indicates the requirements for SQL Server for a small Migration Manager for Email Archives migration (less than 5 Tb).

Processors (cores)

Minimum 4, Recommended 8

Memory

Minimum 16 GB, Recommended 32 GB

Hard disk

Disks should be configured as per Microsoft SQL Server best practices with TempDB, databases and logs on separate disks.

Virtualization

Supported, however performance may be impacted if resources mentioned above are not dedicated.

The table below indicates the requirements for SQL Server for a medium Migration Manager for Email Archives migration (less than 20 Tb).

Processors (cores)

Minimum 4, Recommended 16

Memory

Minimum 32 GB, Recommended 64 GB

Hard disk

Disks should be configured as per Microsoft SQL Server best practices with TempDB, databases and logs on separate disks.

Virtualization

Supported, however performance may be impacted if resources mentioned above are not dedicated.

The table below indicates the requirements for SQL Server for a large Migration Manager for Email Archives migration (more than 20 Tb).

Processors (cores)

Minimum 16, Recommended 32

Memory

Minimum 64 GB, Recommended 128 GB

Hard disk

Disks should be configured as per Microsoft SQL Server best practices with TempDB, databases and logs on separate disks.

Virtualization

Not normally supported. Contact Quest Support if virtualization is the only possibility.

Migration Manager for Email Archives keeps track of every item it exports/imports for auditing purposes. It places a reliance on SQL Server for this task. An adequately prepared SQL Server that meets the recommended specification is essential for a fast migration. Ensuring that an adequately prepared SQL Server which meets the recommended specification is essential for a fast migration.

NOTE: Performance of the migration will be impacted if the SQL Server environment is not sufficient for the needs of the migration.

Sharing

We recommend that Migration Manager for Email Archives SQL servers run a single SQL Server instance only, with no other applications or services running on the servers. SQL Server needs to fully utilize the server resources, and another application may introduce contention issues that will result in undesirable performance.

CPU Considerations

The power of a server is not necessarily determined by the CPU speed in terms of cycles per second. Factors such as the server architecture and number and type of processors and cores can provide a far greater benefit over increasing CPU speed.

Hyper-threading technology is said to provide up to 30% improvement in performance. These processors contain two architectural states on a single processor core, making each physical processor act as two logical processors. However, the two logical processors must share the execution resources of the processor core, so performance gains may not be attained and in some circumstances can even lead to degradation of performance.

Multi-core technology provides similar performance to a comparable multi-CPU server. These processors contain multiple complete processor cores, which act as complete physical processors. Each physical core has its own architectural state and its own execution resources, so the performance gains are reliable.

With the ever-increasing number of processor core combinations and high clock speeds, the traditional x86 Front Side Bus architecture can start to become a bottleneck beyond eight processor cores. A popular and cost-effective method of scaling up the x86 architecture is to use an architecture that supports non-uniform memory access (NUMA). Processors and memory are grouped into nodes that have high-speed local access. However, access to memory co-located with other processor nodes is slower. Therefore, the operating system (and potentially application software) needs to be NUMA-aware and optimized to make the best use of processors, cores, and their associated resources. Windows server and SQL Server support NUMA.

NOTE: See the Microsoft TechNet article: How SQL Server supports NUMA.

The recommended number of processor cores can be composed of either physical CPUs or similar combination of multi-core CPUs, but the sizing should not be based on hyper-threaded logical cores.

NOTE: Hyper-threading is not recommended to improve the database performance due to potential performance problems when the database places a load on the memory. See the Microsoft Knowledge Base article 322385 http://support.microsoft.com/kb/322385 and the MSDN article "Be aware: To Hyper or not to Hyper" for further information. If hyper-threading is to be used, particular attention should be paid to the MAXDOP setting as described in KB322385.

In most cases, the SQL Server instance should manage the CPU resources. Do not set the CPU affinity mask unless absolutely necessary, as this can significantly impact the performance. When running multiple SQL Server instances, the most common reason for setting the CPU affinity mask is to prevent an instance being starved of resources.

セルフ・サービス・ツール
ナレッジベース
通知および警告
製品別サポート
ソフトウェアのダウンロード
技術文書
ユーザーフォーラム
ビデオチュートリアル
お問い合わせ
ライセンスアシスタンス の取得
Technical Support
すべて表示
関連ドキュメント