SQL Serverファイルと拡張サイズをSANのブロックサイズに合わせる必要がありますか？
私たちの（Hitachi）SANは42MBブロックのデータを処理します。これは階層型ストレージであるため、ディレクターがストレージを昇格/降格するタイミングを決定するときに各ブロックが評価されます。特定のLUNを特定の層に「固定」する政治的重みがないため、SQL Server（2008 R2 Enterprise）インスタンスを成功させるためにできる限りのことをしようとしています。
そのため、ファイルサイズとファイルの拡大サイズを42の倍数に変更することにメリット/デメリットがあるかどうか疑問に思っていました。データベースの例はSIZE=57886MB とともに FILEGROWTH=5124MB。
余分な読み取りの可能性があると思いますが（（42 * 1024）/ 8 = 8601.6、ただし（42 * 1024）/ 64 = 672以降）、ここですべての概念を完全に把握しているかどうかはわかりません。
42MBユニット（日立はこれもページと呼んでいますが、とても便利です）。は、スペースがLUNに割り当てられる基本的なアロケーションユニットです。したがって、動的プロビジョニングを使用すると、LUNは常に42MBのステップで増加します。これらのHitachi42MBページは、プール内のさまざまなアレイグループから取得されます。
したがって、LUNにさらに多くのスペースが必要になると、新しい42MBのHitachiページが割り当てられます。最初の8KBのSQLデータページをファイルに書き込むと、42MBのHitachiページが割り当てられます。 SQLデータページの後続の書き込みは、いっぱいになるまでこの42MBの領域に移動します。
ここで理解することが重要なのは、42MBのページが1つのパリティレイドグループに送られるということです。たとえば、小さなRAIDグループがある場合：RAID-1 + 0：2D + 2P（2 + 2）（4ディスク）とデータアクセスほとんどがシーケンシャルです。これは、ファイルが1つある場合に問題になる可能性があります。
それぞれが4つのディスクを持つ4つのRAID10グループがあるとします。たまたま、サイズが168MBのクラスター化インデックスが1つある重要なテーブルが1つだけあります。
このテーブルへの挿入を開始すると、最初の42MB割り当てページがRAIDグループの1つに配置され、この42MBがいっぱいになると、2番目の割り当てページが別のRAIDグループに割り当てられます。おそらく、4つの42MB割り当てページすべてが4つのRAIDグループに分割されます。 （現時点では、簡単にするために階層化を除外しています）。
理解しておくべき重要なことは、クラスター化されたキーの順序で順番に実行するものはすべて、IOを処理するために常に4つのディスクしか持たないということです。 （書き込み中の場合は2つのディスク..）テーブル全体が16のディスクに分散している場合でも..
16個すべてのディスクを使用したい場合。ファイルグループに4つのファイル（4つの別々のLUN上）を作成し、その上にテーブルを作成する必要があります。少なくとも、SQLが「4つの42MBの割り当てページにわたってデータをストライピングしている」ことがわかりました。
これは、トランザクションログファイルで最も問題になる可能性があります。たった1つのファイルでシーケンシャルです。ここで実行できる唯一の「調整」は、そのプールで使用されるRAIDグループを可能な限り大きくすることです。矛盾する連結アレイグループRAID514 + 2 OR RAID5 28 + 4は、RAID 10ではなくRAID5であるにもかかわらず、私が知る限り、RAID 10で最大のRAIDグループであるため、最速である可能性があります。作成できるのは4 + 4は8ディスクです。
複数のLUNがすべて同じプールを共有している複数のデータベースでサーバーを実行している場合、またはすべて同じプールにLUNがあるより一般的な複数のサーバーを実行している場合は、これはそれほど重要ではないことに注意してください。明らかに、一般的な負荷はすべてのレイドグループに均等に分散されるためです。
階層化に関しては、パフォーマンスの目的からは心配する必要はありません。 （ピン留めが許可されていない場合。）42MBの重い割り当てページは高性能層に移動されるため、1つのテーブルが3つの異なる層に分散している状況が発生する可能性があります。どうやらあなたはあなたのテーブルのIO集中的である部分とそうでない部分を持っています...
小さなレイドグループと単一のファイル（実際には単一のLUN）と（高い増分挿入OR重いテーブルのローカライズされた更新/削除OR重いシーケンス読み取り）の組み合わせについて心配する
これが少し役立つことを願っています。
参考文献：