私は心からデベロッパーです-しかし、時々、顧客はこれらの問題に対処するためのきちんとしたDBAを持っていません。
適切なサイズのSQL Serverデータベース（NorthwindまたはAdventureWorksよりも大きいもの、約2〜4 GBのデータとインデックスなど）を扱う場合の戦略/ベストプラクティスは何ですか-複数のファイル/ファイルグループを使用していますか？
もしそうなら：いくつ？なぜ？
「すべてのための1つのファイルグループ」アプローチから離れるタイミングを決定するための基準は何ですか。
* database size?
* database complexity?
* availability / reliability requirements?
* what else?
複数のファイルグループを使用する場合、いくつ使用しますか？データ用、インデックス用、ログ用 データのいくつか（いくつ）？あなたの選択の理由は何ですか-なぜあなたはその正確な数のファイルグループを使用するのですか:-)
ヒント、ポインタ、考えをありがとう！
乾杯、マーク
回答:
基本的な経験則は、競合を避けるためにファイルを異なるボリュームに分離することですが、得られるパフォーマンス向上の量は、I / Oサブシステムとワークロードによって大きく異なります。たとえば、単一の物理スピンドル上の複数のファイルはパフォーマンスが低下する限り吸い込みますが、ボリュームがRAID 10アレイから数百のドライブを備えたSAN LUN上にある同じ配置でも問題ありません。ディスクキューの長さカウンターは、I / Oのボトルネックがあるかどうかを判断する最も簡単な方法です。
データベースのI / Oパターン（読み取り専用、読み取り主に、読み取り書き込み、書き込み主に、書き込み専用）を見て、それに基づいています。また、適切なRAIDレベルを選択し、ディスクパーティションオフセット、RAIDストライプサイズ、およびNTFSアロケーションユニットサイズが正しく設定されていることを確認する必要があります。一部の人々は、非クラスター化インデックスを個別のファイルグループに分離することを好みますが、ここでのパフォーマンスの向上は、上記で説明したように異なります。
パフォーマンスだけでなく、管理性と回復性も考慮する必要があります。100GBデータベース用の単一のモノリシックデータファイルがあるということは、復元の単位がそのファイルであることを意味します。4つの25GBファイルグループに分割すると、データベースの部分的な可用性と断片的な復元を使用して、破損した場合に1つのファイルグループのみを復元できます。テーブルとインデックスを複数のファイルグループにパーティション分割することにより、データベースのどの部分がメンテナンス操作（インデックスの断片化の削除など）の影響を受けるかを制限することもできます。
Tempdbはまったく特別なケースであり、tempdbを分割する理由と方法について説明している私のブログ投稿で指摘します-そこには多くの誤解があります。
ここでは、「掃引の一般化」の推奨事項を提示せずに、読者が読むことができるホワイトペーパーとブログ投稿を多数紹介します。
ホワイトペーパー：データベースの部分的な可用性
ブログ投稿：TF 1118の誤解（tempdbレイアウト）
これがあなたを助けることを願っています！
データベースをさまざまなファイルグループに分割する決定は、テーブルの現在のサイズと将来の成長を分析した後に行う必要があります。私の意見では、大規模なデータベースまたは数百万行のテーブルがない限り、長所と短所を慎重に検討する必要があります。
特定の前提の下で興味深いいくつかのシナリオがあります。
環境を分析して、ファイルグループがSQL Serverの成長、使用、およびパフォーマンスのニーズに役立つかどうかを判断する必要があります。
複数のファイルグループに移動するためのいくつかの重要なインジケーター（この記事から）：
ファイルグループによってデータベースのパフォーマンスが向上する場合は、運用サーバーに変更を実装する前に、コードを記述し、ステージング環境でプロセスをテストします。変更を実装する前にいくつかの測定値を準備し、それらを前後に比較します。これらのプロセスは非常にリソースを消費し、時間がかかるため、メンテナンス期間中にこれらの手順を実行してください。
新しいオブジェクト（テーブルとインデックス）を作成するときは、オブジェクトが正しいファイルグループに作成されることを忘れないでください。期待されるパフォーマンスを確保し、データベースオブジェクトが正しいファイルグループにあり、必要に応じて修正されることを定期的に検証してください。