web-dev-qa-db-ja.com

SQL Server 2005/2008-複数のファイル/ファイルグループ-いくつですか？どうして？

私は根本的に開発者です-しかし、時々、これらの問題に対処するためのきちんとしたDBAが顧客にいないため、私は決定を求められます...

適切なサイズのSQL Serverデータベース（NorthwindまたはAdventureWorksよりも大きいもの、約2〜4 GBのデータとインデックスなど）を扱う場合の戦略/ベストプラクティスは何ですか？複数のファイル/ファイルグループを使用していますか？

もしそうなら：いくつですか？なぜ？

「すべてに1つのファイルグループ」のアプローチから移行するタイミングを決定する基準は何ですか。

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

複数のファイルグループを使用する場合、いくつ使用しますか？ 1つはデータ用、もう1つはインデックス用、もう1つはログ用ですか。データ用にいくつか（いくつ）？選択する理由は何ですか-なぜファイルグループの正確な数を使用するのですか:-)

ヒント、ポインタ、考えをありがとう！

乾杯、マルク

sql-serversql-server-2005sql-server-2008groups
11
marc_s

基本的な経験則は、競合を回避するためにファイルを異なるボリュームに分割することですが、パフォーマンスの向上量は、I/Oサブシステムとワークロードによって大きく異なります。たとえば、単一の物理スピンドル上の複数のファイルは、パフォーマンスの点で問題がありますが、ボリュームがSAN RAID 10アレイからの数百のドライブを備えたLUNにある場合の同じ配置は、ディスクキューの長さのカウンターは、I/Oボトルネックが発生しているかどうかを確認する最も簡単な方法としてあなたの友人です。

データベースのI/Oパターン（読み取り専用、読み取り専用、読み取り/書き込み、書き込み専用、書き込み専用）を調べて、それに基づいています。また、適切なRAIDレベルを選択し、ディスクパーティションのオフセット、RAIDストライプサイズ、およびNTFSアロケーションユニットサイズが正しく設定されていることを確認する必要もあります。一部の人々は、非クラスター化インデックスを別のファイルグループに分離することを好みますが、ここでのパフォーマンスの向上は、上記で説明したように異なります。

パフォーマンスだけでなく、管理性と回復可能性も考慮する必要があります。 100GBデータベース用の単一のモノリシックデータファイルがあるということは、復元の単位がそのファイルであることを意味します。それを4つの25GBファイルグループに分割すると、データベースの部分的な可用性と段階的な復元を使用して、破損した場合に単一のファイルグループを復元するだけで済みます。テーブルとインデックスを複数のファイルグループにパーティション分割することで、データベースのどの部分がメンテナンス操作（インデックスの断片化の削除など）の影響を受けるかを制限することもできます。

Tempdbはまったく特殊なケースです。tempdbを分割する理由と方法についてすべて説明している私のブログ記事を紹介します。そこには多くの誤解があります。

ここで「一般化」の推奨事項を提示せずに、ホワイトペーパーとブログ投稿の束を紹介します。

これがお役に立てば幸いです！

16
Paul Randal

データベースを複数のファイルグループに分割する決定は、テーブルの現在のサイズと将来の成長を分析した後で行う必要があります。私の意見では、大規模なデータベースや数百万行のテーブルがない限り、長所と短所を慎重に検討する必要があります。

特定の前提で興味深いシナリオがいくつかあります。

  • 2つのファイルグループ：データとインデックス
  • 3つのファイルグループ：読み取り専用テーブル、読み取り/書き込みテーブル、インデックス
  • 複数のファイルグループ：読み取り専用、読み取り/書き込み、インデックス、キーテーブル1、キーテーブル2、...

環境を分析して、ファイルグループがSQL Serverの成長、使用、パフォーマンスのニーズに役立つかどうかを判断する必要があります。

複数のファイルグループに移動するためのいくつかの重要なインジケーター（ この記事 から）：

  • ディスクキューイングがアプリケーションとユーザーエクスペリエンスの問題を引き起こしている場合
    • その場合は、追加のディスクドライブを新しいファイルグループハウジングで活用することを検討してくださいIO集中的なテーブル
  • 特定のテーブルがデータベースの10％以上の場合
    • この場合は、これらの特に大きなテーブルを、基盤となる個別のディスクドライブ上の個別のファイルグループに移動することを検討してください。
    • 残りのテーブルに比例したテーブルサイズに応じて、個々のテーブルのファイルグループを構築することを検討してください。
  • 大きなテーブルで非クラスタ化インデックスとデータスペースが等しい場合
    • この場合は、非クラスター化インデックスからデータとクラスター化インデックスを分割することを検討してください。
  • ほぼ同じ割合の読み取り専用データと読み取り/書き込みデータがデータベースに存在する場合
    • この場合は、読み取り専用データを別のファイルグループに読み取り/書き込みデータとして分割することを検討してください。
  • データベースのメンテナンスを実行するのに十分な時間がない場合
    • この場合は、大きなテーブルを異なる基盤となるディスク上の別々のファイルグループに分割し、並行してメンテナンスを実行することを検討してください。
  • ビジネスまたはアプリケーションが大幅に変化し、データがはるかに高い速度で増加するとき
    • この場合、ユーザーと協力して潜在的な成長を理解することを検討してください。
  • アーカイブされたデータが本番データと同じデータベースにある場合
    • その場合は、個別のファイルグループ、またはこのヒントの1つ以上の手法（SQL Serverでのデータのアーカイブ）を検討してください。

ファイルグループがデータベースのパフォーマンスを向上させる可能性があることがわかった場合は、コードを記述し、ステージング環境でプロセスをテストしてから、運用サーバーに変更を実装してください。変更を実装する前にいくつかの測定を準備し、その前後で比較します。これらのプロセスは非常に多くのリソースと時間がかかる可能性があるため、メンテナンス期間中にこれらの手順を実行します。

新しいオブジェクト（テーブルとインデックス）を作成するときは、オブジェクトが正しいファイルグループに作成されていることを忘れないでください。期待されるパフォーマンスを確保し、データベースオブジェクトが正しいファイルグループにあることを定期的に検証して、必要に応じて修正してください。

4
splattne