私が使う SQL Server 2008 R2
そして、各インデックスのFILL FACTORプロパティの値を設定します。このプロパティの最良の値を計算するためのレシピを探します(レコードを挿入するときにパフォーマンスが向上します)。また、このプロパティに遅延値を設定することで、クエリのパフォーマンスを測定する方法も示しています。
よろしくお願いします。
FILL FACTORに関するすべての答えは1つではありません。これは、データ変更がデータベース全体または特定のインデックスでどのように行われるかに大きく依存します。デフォルトでは、デフォルトで0(100)に設定されており、ページ内にスペースがほとんどありません。これが意味することは、ページの中央に挿入するとページ分割が発生することです。
Page Splits/secカウンターを監視し、高いレートが表示されている場合は、フィルファクターを再検討することをお勧めします。ただし、Fill Factorを低くしてディスク容量を増やしていくので、盲目的に低めに設定しないでください。そして当然、データを格納するページが増えるため、IOの読み取りが多くなります。
Fill Factorに関する私の回答 を参照することをお勧めします。これは別のタイプの質問ですが、FILL FACTORとそれがどのように影響するかについてのより良い考えを与えるはずです。
基本的な考え方は、ページをできるだけいっぱいにすることです。データページにパックされる行が多いほど、バッファープールで読み取って保持する必要があるページが少なくなります。
つまり、最終的には、すべてのページを100%データで満たす必要があります。
しかしながら:
すべてのページがいっぱいになると、いくつかの問題が発生します。
ページ分割には他の原因がありますが、これらが最大の原因です。
上記のすべてが断片化を引き起こします。今はそれは悪いですが、奇妙な方法で良いです。それは、適切なフィルファクターを決定するのに役立つ唯一のことです。その理由を説明します。
あなたがすることは:
上記のいずれかが当てはまるかどうかを確認します。行うインデックスについては、次の操作を行います。
これは時間をかけて評価する必要があることに注意してください。ワークロード(データ変更)は、時間の経過とともに変化する可能性があります。
また、現在の問題が何であるかを覚えておいてください。ページの分割により、ログファイルに余分な負荷が発生します(大量になる可能性があります)。データファイルへの追加書き込み(より高いチェックポイントピーク)。また、先読みは断片化のために効果が低くなります。ただし、Fill Factorが低いと、バッファスペースが消費され、読み取り負荷が増加します。
非常に注意すべきことの1つは、pagesplits/secカウンターが本当に信頼できないことです。彼らはすべてのページ分割を追跡します。 (SQL 2012の方が優れています)allとは、インデックスの最後にレコードを挿入する場合、続行するには新しいページをインデックスに追加する必要があるということです。新しいデータページの追加も、ページ分割としてカウントされます。しかし、実際には何も分割されていません。そのため、pageslit/secカウンターを見ると、クラスターインデックスへの挿入にはページ分割が含まれますが、問題はありません。したがって、他の事実との関連でこのカウンターを見てください。次に例を示します。説明のつかない高トランスログのロードと高順序の挿入および高ページ分割/秒。
警告の最後の言葉。特に大きなテーブルでは。常にインデックスの現在のページ密度を確認し、異なるFILL FACTORを使用してインデックスを再構築した場合のサイズへの影響を計算してください。 (100%のページ密度で新しい50%のフィルファクターでインデックスを再構築すると、実質的にインデックスのサイズが2倍になります)