データベースをファイルグループに分割する必要がありますか？今は30GBです
現在、会社のデータベースサーバーをWindows 2000/Sql Server2000からWindows2003 R2/Sql Server2005に変更しています。 30のデータベースを保持し、各データベースのサイズは約7 GBですが、そのうちの1つは30GBです。そして今、私はこのデータベースでファイルグループを使用する機会を利用すべきかどうか疑問に思っています。しかし、私はこれまで使用したことがなく、データベースの内容がそれほど優れているかどうかはわかりません。しかし、それは経済システムなので、過去8年間の生産において、多くの歴史的な「読み取り専用」情報を保持していると思います。
分割する必要があるかどうかについて、誰かが私にいくつかのヒントを教えてもらえますか？現在、ログファイル用とデータベース用の2つの別々のディスクがあります。
誰かが私にいくつかの入力を与えることができれば幸いです:)
データベースを複数のファイルグループに分割しますか、それとも既存のプライマリファイルグループに複数のファイルを追加しますか？
最初のケースでは、オブジェクト（テーブル、インデックス）を新しく追加されたファイルグループに移動する必要があります。そうしないと、オブジェクトは空のままになります。そのためには、オブジェクトの使用パターンを十分に理解して、どのオブジェクトがどこに移動するかを判断できるようにする必要があります。その後の利点は、アクセス方法に応じて、ファイルグループを個別のIOパス（個別のディスク/ LUN）に割り当てることができることです。もう1つの利点は、バックアップ/復元をより細かく管理できることです。これにより、断片的な復元を実行でき、個々のファイルグループのバックアップを実行できます。データベースにファイルグループを割り当てることは設計時間の決定であり、あなたにとっては少し遅れていると思います。
2番目のケースでは、IOを複数のディスクに分散させるために、PRIMARYファイルグループにファイルを追加するだけです。実際にdo IOの問題があり、複数のIOパス（つまり、ファイルを配置するための個別のディスク/アレイ/ lun）がない限り複数のファイルを追加しても利点はありません。データベースを同じサイズのN個のファイルにスプリントすることを推奨するアドバイスに出くわすかもしれません。NはCPUコアの数ですが、SQL2005/2008はSQL2000よりもはるかに優れたSGAM/GAM割り当ての競合を処理し、もはや分割が必要です。
問題と環境についてのあなたの説明から、私は率直に言って分割を行う理由はないと思います：あなたは断片的な復元を可能にするための派手な復元計画を立てるつもりはありません（そしてそれはかなり小さい30Gbだけです）、そしてとにかくディスクが1つしかないため、複数のファイルを使用してもメリットはありません。
専用ディスクが2つしかなく、トランスログ用に1つ必要なため、データベースをファイルグループに分割しても、パフォーマンスはそれほど向上しないと思います。
私はそれを分割しません。
ファイルグループに関する情報はこちら 。それらを別々のドライブに配置した場合にのみ、実際にパフォーマンスが向上します。ファイルグループの他の用途は、読み取り専用テーブルを分離し、アクティブなファイルグループのみをバックアップできるようにすることです。