MicrosoftSQLマスターのBrentOzarによると、彼はキャリアを通じて、データベースのパフォーマンスを調整するというひどい決断を下しました。私たちにとって幸運なことに、私たちは彼の過ちから利益を得ることができ、私たち自身ですべてを理解する必要はありません。彼は、QuestのDatabase Training Days Webキャストシリーズで、苦労して得た知恵を無料で共有しました。
彼のセッションの1つで、「インデックスの最適化が役に立たない理由」を学びました。実際、データベースのパフォーマンスが低下している可能性があり、ブレントがその理由を説明してくれました。その過程で、SQL Serverのパフォーマンスを最適化する際に、何を測定しているのかを知ることの重要性を強調しました。
内部と外部の断片化
ブレントは、SQLServerが8KBの「ページ」にデータを格納する方法についての簡単なチュートリアルを提供してくれました。新規または再構築されたインデックスでは、ページはすべていっぱいで、順番に保存されます。ただし、データが追加されると、ページが分割されます。すべてのページがいっぱいになるわけではなく、順序が狂っています。これは、内部と外部の断片化の重要な違いです：
- 外部の断片化–ページが故障していることを指します
- 内部断片化–ページの空きスペースを指します
ページ分割を少なくする
多くのデータベース専門家は、データベースの断片化の尺度としてページ分割に焦点を当てていますが、空のテーブルに新しい行を追加するときと新しいページを追加するときの両方でページ分割が発生するため、この数値は無意味であるとブレントは説明しました。ですから、結局それは役に立ちません。
外部の断片化が事態を悪化させる方法
このセッションで、ブレントは、ページの順序はメンテナンスタスク、RAMでのクエリの実行、ディスクからのデータの読み取りの速度にあまり影響を与えないため、外部の断片化はデータベースのパフォーマンスの有用な指標ではないと主張しました。そのため、インデックスを再編成して再構築することで外部の断片化を修正しようとするデータベースの専門家は、バックアップを膨らませ、メンテナンスウィンドウの時間を増やすことで、実際にパフォーマンスを低下させています。
フィルファクターを設定してページにスペースを残して外部の断片化を削減しようとするデータベースの専門家も、修正しようとしている問題よりも深刻な問題を引き起こしています。これは主に、インデックスの途中のポイントにデータを挿入する必要がほとんどないためです。したがって、個々のページに配置するデータを減らしてページを整理しようとすると、実際には内部の断片化が発生します。
待機時間の監視
代わりに何をすべきですか？ブレントは、フィルファクターをデフォルトの100％（または少なくとも80％以上）に設定してから、インデックスを再構築して再度パックすることをお勧めします。次に、適切なパフォーマンスチューニング数（待機時間）の監視に焦点を合わせます。データベースインスタンス全体の待機時間のさまざまな側面を表示する最良の方法の1つは、パフォーマンス監視ツールを使用して、プロセスが停止している場所を正確に特定することです。
インデックスの断片化、待機時間の統計、インデックスのメンテナンスについて行うべきことに関するブレントの洞察の詳細については、オンデマンドでウェブキャストを聞いてください。
Questのデータベーストレーニングデーを通じて、データベースのパフォーマンスに関するより専門的なアドバイスにアクセスすることもできます。