私たちのデータベースは現在、およそ8GBのデータ（テーブル行、インデックス、フルテキストカタログ）を含むPRIMARYという1つのファイルグループのみを持っています。
これを2次データファイルに分割する適切なタイミングはいつですか？知っておくべき基準は何ですか？
私たちのデータベースは現在、およそ8GBのデータ（テーブル行、インデックス、フルテキストカタログ）を含むPRIMARYという1つのファイルグループのみを持っています。
これを2次データファイルに分割する適切なタイミングはいつですか？知っておくべき基準は何ですか？
回答:
この質問には2つの部分があります。新しいFILEGROUPを追加するタイミングと、ファイルグループに新しいFILEを追加するタイミングです。最初に理論について話しましょう：
主な理由はパフォーマンスであるというマークの権利。
2番目の理由は、災害復旧です。SQL Server 2005以降では、ファイルグループの復元を実行できます。災害が発生した場合、最初にプライマリファイルグループのみを復元し、クエリのためにデータベースを部分的にオンラインにすることができます。ユーザーは、他のファイルグループを復元しているときにクエリを実行できます。これは、すぐには必要ない可能性がある履歴データが大量にあるデータベース、またはアクセスするために履歴データを必要とせずに現在のテーブルにデータをロードする必要があるデータウェアハウスに役立ちます。
もう1つの理由は、データグループの読み取り/書き込みプロファイルです。常に書き込まれているデータと、読み取りアクティビティが頻繁に発生する他のデータがある場合、それらのニーズに対応するためにさまざまなタイプのストレージを構築できます。重い書き込みのものをraid 10に置き、read-biasされたものをより安いraid 5のままにしておくことができます。
それでは、ファイルとファイルグループについて話しましょう。SQL Serverにオブジェクトを配置するときは、ファイルグループレベルに配置する必要があります。テーブルまたはインデックスをファイルグループに配置できますが、特定のファイルを選択することはできません。これまで説明してきたことは、ファイルグループをいつ追加するかについてでしたが、いつファイルを追加しますか？
ストレージを設計していて、80台のハードドライブがある場合、いくつかの方法で分割できます。
ストレージサブシステムが異なれば、パフォーマンスプロファイルも異なります。12〜16個のドライブアレイで最高のパフォーマンスを発揮したSANをいくつか使用しましたが、それより大きなものではパフォーマンスが向上しませんでした。別の例は、マルチパスを備えたSANです。サーバーをストレージに接続している複数のHBAがあり、マルチパスソフトウェアが実際にアクティブ/アクティブでない場合、負荷を分散するためにパスごとに1つのアレイが必要になる場合があります。4つのパス、4つのドライブプールは、これらのタイプのドライブのパフォーマンスを向上させます。
これらの場合、Windowsでは4つの異なるアレイ、4つの異なるドライブ（マウントポイントを使用しない限り、さらには異なるフォルダーである場合）となり、SQL Serverには4つの個別のファイルが必要になります。これらの個別のファイルは、同じファイルグループに含めることができます。
主な理由はパフォーマンスです。プライマリファイルグループのディスクドライブでIOPS容量が不足した場合、ストレージ構成に応じてIOPSを複数のディスク/ LUNに分割するには、2番目のファイルグループに拡張する必要があります。
編集：ブラッドウィルソンはSSDに関して良いコメントをしました。複合SSD / SATA / FCストレージシステムを使用している場合、さまざまな種類のストレージにさまざまなファイルグループを配置することができます。その後、極端なIOPS要件テーブルをSSD filegropusに配置できますが、履歴/統計テーブルは安価なSATAファイルグループに保存できます。
また、この質問には回復可能性/データ可用性の側面があることも指摘しておきます。複数のファイルグループを使用し、プライマリファイルグループにユーザー定義のオブジェクトを配置しないことで、オンラインリストアをより柔軟に有効にすることができます。これにより、ファイルグループレベルで断片的な復元が可能になります。
オンライン復元は、2005年以降のSQL ServerのEnterpriseおよびDeveloperエディションで利用可能です
頭に浮かぶもう1つの考えは、読み取り専用の静的参照データをトランザクションデータから分離することです。大規模なデータベースの場合、これにより、バックアップの実行に必要な時間および/またはスペースを削減できます。