I/O サブシステムの適切な構成は、SQL Server システムのパフォーマンスと操作の最適化に欠かせないものです。ここでは、SQL Server のストレージ構成に関して SQL Server チームが推奨する最も一般的なベスト プラクティスをいくつか紹介します。

SQL Server の I/O 特性とアプリケーションの特定の I/O 要件や特性を理解する

SQL Server アプリケーションのストレージを適切にデザインして配置するには、アプリケーションの I/O 特性と SQL Server の I/O パターンの基本を理解する必要があります。既存のアプリケーションに関するこの情報をキャプチャするには、パフォーマンス モニタが最適です。次に、ここで確認する必要がある点をいくつか示します。

• アプリケーションの読み取りと書き込みの比率。
• 通常の I/O 速度 (1 秒あたりの I/O 数、I/O の MB/秒とサイズ)。次の perfmon カウンタを監視します。

1. 1 秒あたりの平均読み取りバイト数、1 秒あたりの平均書き込みバイト数
2. 1 秒あたりの読み取り数、1 秒あたりの書き込み数
3. 1 秒あたりのディスク読み取りバイト数 (Avg. Disk Read Bytes/sec)、1 秒あたりのディスク書き込みバイト数 (Avg. Disk Write Bytes/sec)
4. ディスク読み取りの平均秒数 (Avg. Disk sec/Read)、ディスク書き込みの平均秒数 (Avg. Disk sec/Write)
5. ディスク キューの平均の長さ (Avg. Disk Queue Length)

• 実際のシーケンシャル I/O とランダム I/O の量。このアプリケーションが主に OLTP アプリケーションとリレーショナル データ ウェアハウス アプリケーションのどちらとして使用されるか。

SQL Server の I/O の主な特性については、「SQL Server 2000 I/O Basics」(英語) を参照してください。

スピンドルを増やすかその速度を上げるとパフォーマンスが向上する

• 許容可能な待機時間と I/O 要件をサポートできる、十分な数のスピンドルを確保します。
• バックアップ、復元、データベースの部分可用性などの管理要件のためにファイル グループを使用します。
• データ ファイルを使用して、データベースを特定の I/O 構成 (物理ディスクや LUN など) 全体に “ストライプ化” します。

ストレージのデザインを “必要以上に” 最適化しようとしない (一般的に、シンプルなデザインの方がパフォーマンスや柔軟性に優れている)

• アプリケーションをよく理解していない場合は、オブジェクトを個別のスピンドルに選択配置して I/O を必要以上に最適化しようとしないでください。
• あらかじめデータ増加に備えた戦略を立てておきます。データ サイズが大きくなると、データ ファイル、LUN、および RAID グループの増加の管理が難しくなります。後から運用配置でデータ ファイルまたは LUN のバランスを再調整するよりも、あらかじめデータ増加に備えてデザインすることをお勧めします。

配置前に構成を検証する

• SQL Server の配置前に、I/O サブシステムの基本的なスループット テストを実行します。このテストで、許容可能な待機時間と I/O 要件を実現できることを確認します。このテストに使用できるツールの 1 つに SQLIO があります。このツールにはドキュメントが付属しており、I/O サブシステムのテストの基礎が記載されています。SQLIO ディスク サブシステム ベンチマーク ツールをダウンロードしてください。
• SQLIO テストを実行する目的は、SQL Server の正確な I/O 特性をシミュレートすることではなく、一般的な SQL Server I/O タイプの I/O サブシステムで実現できる最大スループットをテストすることにあります。
• SQLIO の代わりに IOMETER を使用することもできます。

常にログ ファイルを RAID 1+0 (または RAID 1) ディスクに配置して次のことを実現する

• ハードウェア障害に対する保護の強化。
• 書き込みパフォーマンスの向上。
  注 : 通常、RAID 1+0 を使用すると、書き込みを集中的に行うアプリケーションのスループットが向上します。パフォーマンスの向上レベルは、ハードウェア製造元の RAID 実装によって異なります。RAID 1+0 の代わりに最もよく使用されるのは RAID 5 です。通常、RAID 1+0 を使用すると、データ保護に使用する他のすべての RAID レベル (RAID 5 を含む) よりも書き込みパフォーマンスが向上します。

物理ディスク レベルでデータとログを分離する

• 分離できない場合は (統合 SQL 環境など)、I/O 特性を検討して同様の I/O 特性 (すべてのログ)
  を共通のスピンドルでグループ化します。
• 異種ワークロード (I/O や待機時間の特性がまったく異なるワークロード) を組み合わせると、全体的なパフォーマンスが低下する可能性があります (たとえば、Exchange と SQL のデータを同じ物理スピンドルに配置した場合など)。

TEMPDB データベースの構成を検討する

• SQL Server のインストール後に、TEMPDB を適切なストレージに移動してサイズを設定しておきます。
• TEMPDB を RAID 1+0 に配置すると、(TEMPDB の使用量によっては) パフォーマンスが向上します。
• TEMPDB データベースでは、次の項目 8 で説明するように、CPU ごとに 1 つのデータ ファイルを作成
  します。

データ ファイル数と CPU 数を合わせると、割り当てが集中的に行われるワークロードでスケーラビリティが
得られる

• ホスト サーバー上の CPU ごとに 0.25 ～ 1 のデータ ファイル (ファイル グループ別) を作成することをお
  勧めします。
• このことは、特に TEMPDB に当てはまります。TEMPDB では、CPU ごとに 1 つのデータ ファイルを作成することをお勧めします。
• デュアル コアは 2 つの CPU と見なされますが、論理プロセッサ (ハイパースレッディング) は見なされません。

SQL Server の基本を確認する

• SQL Server では、空き領域が多いファイルへの割り当てを優先する比例入力アルゴリズムが使用されるので、データ ファイルのサイズは均等にします。
• データとログ ファイルのサイズを事前に設定します。
• AUTOGROW は使用せずに、これらのファイルのサイズ増加には手動で対応します。安全上の理由から AUTOGROW をオンのままにすることはできますが、データ ファイルのサイズ増加を事前に管理する必要があります。

ストレージ構成の基本を確認する

• ストレージ製造元が推奨する最新の HBA ドライバを使用します。
• HBA 製品の Web サイトから入手したストレージ製造元固有のドライバを使用します。
• I/O ボリュームに応じて HBA ドライバ設定をチューニングします。通常、ストレージ製造元からドライバ固有の設定が指定されます。ただし、多くの場合、キューの深さの既定値は SQL Server の I/O ボリュームをサポートするには不十分です。
• ストレージ アレイ ファームウェアが最新の推奨レベルであることを確認します。
• マルチパス ソフトウェアを使用して HBA および LUN 全体のバランスを保ち、適切に機能していることを確認します。
• 構成を簡略化し、可用性を高めます。
• Microsoft Multipath I/O (MPIO) : 製造元は、Microsoft が提供する Driver Development Kit を利用して Device Specific Module (DSM) を構築します。