SQLServerトランザクションログRAID
SQL Serverサーバーは3つあり、各サーバーには約5つまたは6つのデータベースがあります。これらのサーバーを新しいSANに移動する過程にあり、最適なRAID構成に取り組んでいます。現在、すべてのデータベースのすべてのログファイルがRAIDアレイを共有しています。このRAIDアレイには、ログファイル以外は何もありませんが、すべてのデータベースがログファイルにこの同じアレイを使用します。
ログファイルを別々のディスクに保存するのが最善であることを読みました。しかし、私たちの場合、すべてのログファイルが存在する約8台のドライブを備えた1つの大きなアレイが最適かどうかはわかりません。または、4つの2つのディスクアレイを作成し、いくつかの大規模なデータベースにログファイル専用のディスクを提供する方がよいでしょうか。
ログ
ログは、ほとんどが順次アクセス構造です。簡単に言うと、「このデータをこのブロックに書き込む」というエントリのリングバッファとして表示できます。 DBエンジンが書き込みを発行すると、実際にはこれらのエントリの1つがログに書き込まれます。次に、ログリーダープロセスが非同期でフォローアップし、ブロックをディスクに書き込みます。
ディスクヘッドのアクティビティが比較的少ないため、ログは比較的高速です。ただし、ログ書き込みアクティビティが同じディスク上のランダムアクセスアクティビティと競合している場合、競合はログ書き込みパフォーマンスに大きな影響を与える可能性があり、DB全体のパフォーマンスに影響します。
さらに、ログを別のディスクに書き込むことで、冗長性を測定できます。データをバックアップする場合、バックアップは復元されたデータベースでロールフォワードできるため、エントリをログに記録します。これは、災害がデータ損失を引き起こすためにログとデータボリュームの両方を取り出さなければならないことを意味します。
これらの理由から、データボリュームとは別のアレイ（異なる物理ディスク）にログを記録する必要があります。単一のミラーリングされたペアは、競合がない場合、非常に大量のログトラフィックを処理できるため、トランザクション量が非常に多い場合を除いて、それ以上のものはおそらく必要ありません。ただし、ログボリュームでディスクアクティビティを生成しているものが他にないことを確認してください。
TempDB
TempDBを多用するプロセスがある場合、これをRAID-10ボリュームに配置すると、RAID-5よりも優れた書き込みパフォーマンスが得られるため、パフォーマンス上のメリットが得られます。 （以下のライトバックキャッシュに関する注記を参照してください）。データとinedexをRAID-5ボリュームに配置し、TempDBを多用するプロセスがある場合は、TempDBを別のRAID-10ボリュームに配置することでメリットが得られる可能性があります。データボリュームでもRAID-10を使用している場合、これは問題ではありません。
データとインデックス
データボリュームが非常に大きい場合は、RAID 5、6、50（ストライプRAID-5ブロック）または60にデータを配置できます。データボリュームが小さい場合は、RAID-10を使用できます。データボリュームにRAID-5（または同様のもの）がある場合は、別のTempDBボリュームが必要になる可能性があります。そうでない場合、システムは、単一のRAID-10ボリュームを共有するデータ、インデックス、およびTempDBで問題なく動作します。
ライトバックキャッシング
SANのRAIDコントローラーがバッテリーバックアップをサポートしている場合は、それらにライトバックキャッシュを設定できます。これは、コントローラーが書き込みをRAMディスクへのライトバックを最適化します。ライトバックキャッシングは、RAID-5ボリュームでパフォーマンスを大幅に向上させることができますが、システムに追加の障害モードを追加します。
電源に障害が発生した場合、バッテリーバックアップはキャッシュされたデータを数日間保持します。 SANを再アクティブ化すると、キャッシュされたエントリが書き出されます。理論的には、これはかなり信頼性が高く、おそらく機能します。ただし、ライトバックキャッシュの失敗に関する事例はたくさんあります。
ボリュームごとにライトバックキャッシュをアクティブ化できる場合は、ログで非アクティブにすることを検討してください。このように、前述のように、データベースを復元してログをロールフォワードすることにより、データを破損することなくキャッシュ障害を回復できます。システムをベンチマークして、パフォーマンスが十分であることを確認します。
結論
ログボリュームとデータボリュームを分離します。 RAID 4、5、6、40、50、または60を使用していて、TempDBでのアクティビティが多い場合は、TempDBを別のRAID-10ボリュームに配置することを検討してください。非常に大きなデータボリュームがない限り、RAID-10ボリュームでデータ、インデックス、およびTempDBを共有できます。ログボリュームは、大量のディスクアクティビティのソースとディスクを共有しないでください。
トランザクションログアレイは少なくともRAID1（ミラーリング）である必要があり、1 + 0が推奨されます（ミラーリング+ストライプ）。これには少なくとも4つの物理ドライブが必要です。
RAID 5は、トランザクションログには絶対に使用しないでください。トランザクションログのシーケンシャル書き込みパターンの性質上、データファイルにのみ使用してください。パフォーマンスのために、ログファイルとデータファイルを常に異なる物理アレイに分離する必要があります。
私はそれを2つのアレイに分割するだけです。そうしないと、多くのディスクを浪費することになります。 8台のドライブを備えたアレイが1つある場合は、7台のドライブ容量が必要です。ただし、アレイが4つある場合、ドライブの容量は4つだけです。
もう1つ考慮すべきことは、RAID5に対するRAID1の読み取りと書き込みのパフォーマンスです。理論的には、RAID 1は1x書き込み、2x読み取り、2xシークですが、RAID 5は（N-1）x書き込み、Nx読み取り、1xシークです。 。これは理論的には、実際には読み取り/書き込み/キャッシュパターンとコントローラーが違いを生みます。
ログファイルのディスクアクセスパターンは追加専用です。ログの書き込みは、更新または挿入アクティビティが多いデータベースの全体的なパフォーマンスの決定要因になります。ディスクヘッドシークは、物理IOを実行する時間を支配します。
全体的なパフォーマンスの観点からの目標は、ヘッドの動きが常に最小限になるように、各ログファイルに専用のディスクスピンドルを与えることです。
信頼性を確保するために、この戦略を強化して、各ログファイルが2ディスクハードウェアRAID1を取得するようにします。
ログファイルをSANに保存すると、問題のSANシステムによっては、ディスクヘッドの競合を制御することが困難になる場合があります。
複数の異なるデータベースのログファイルを保存する場合は、4つのディスクで構成されるRAID0/1（または1/0）ではなく、それぞれ2つのディスクで構成される2つの別々のRAID1を使用します。ログファイルアクティビティが最も多いデータベースを選択し、それに独自のスピンドルのセットを割り当てます。
他の場所で提案されているように、RAID5の使用についての考えはすべて却下してください。
少し遅れますが、将来のために答えます。
以前の返信はすべて正しいですが、ローカルドライブ用です。 SAN、NAS（あなたの家のものではなくそれらの大きな商用のもの）で変化します。
ベンダーと入手しているモデルを確認してください。その理由は、ベンダーがRAIDはトランザクションログにとって実際には重要ではないと言っているからです。ベンダーはまた、トランザクションログとデータファイル用の個別のドライブ全体がパフォーマンスの問題を引き起こすため、1つのボリュームに配置する必要があると述べています。
これの一部は、SANでフルドライブを取得しない限り、別のボリュームがヘッドを移動し、パフォーマンスブーストを失うためです。また、ボトルネックはドライブではなくHBAとネットワークになります。
したがって、ベンダーがハードウェアに推奨するものを確認してから、テストと監視を開始してください。
データパスを分離すればするほど、競合が少なくなり、パフォーマンスの面で、配列を分離して各データベース（または最もビジーなデータベース、最大ではないが、あたりのトランザクション数が最も多いデータベース）を提供する方が賢明です。 2番目）独自のログファイルディスク。