2010-12-31 24 views
1

親愛なるエキスパート。 のような理由により、私たちのデータベースにセカンダリデータファイルが必要であると確信しています:可用性の理由から、プライマリデータにシステムデータのみを保存することが常にベストですファイル(Sql2k5以上で、プライマリデータファイルが利用可能である限り、データベースはオンラインになり、できるだけオンラインにしながらシステム以外のデータを修復/復元することができます)。プライマリ・データ・ファイル内のシステム・カタログ・データを取り出し、ユーザ・データをセカンダリ・ファイルに入れると、プライマリ・ファイルは小さくなり、更新や挿入が少なくなり、たとえば不良ディスクセクタが最小化されます。複数のデータファイルと複数のファイルグループ

私のジレンマは、ユーザーデータがプライマリデータファイルにならないように制限する方法です。それが私に出来る見える唯一の方法は、以下の通りです:

  • プライマリファイルグループ
  • セカンダリデータファイルとセカンダリファイルグループを作成し、テーブルのように私の物理的なオブジェクトを作成するための唯一のプライマリデータファイルを維持します/ 2番目のファイルグループのインデックスなど。
  • だから、

、提案してください:

  1. は、二次データ・ファイルとセカンダリファイルグループを持っており、その中にのみ、プライマリ・データ・ファイルをプライマリファイルグループを残すことを常にお勧めしますか?それ以外はお勧めします。
  2. 上記の構成では、サイズが10 GB未満の小さなデータベースでパフォーマンスに何か影響はありますか?

ありがとうございます!

答えて

4

システムとユーザーデータを分離しないでください。それは何も追加しません。実際の生活では、あなたのMDFがそこにあるか、そうではありません。グレーの色合いはあまりありません。私はテラバイトのサイズに

  • つ以上の大きなテーブル
  • 非常に高い負荷に近づいてる

    • (ない:分割については

      、私は1つまたはそれ以上まで、複数のファイルグループを気にしないだろうただ一つの大きなテーブル)

    • たぶん、別のインデックスは、ロード/サイズ/大型テーブル

    に基づいており、私はseparaを持つことができる場合にのみ、各ファイルのLUNまたはRAIDアレイ。ほとんどのデータベースのために、それはそれ

  • +0

    おかげでたくさんのGBN価値はありません:あなたは複数のファイル

    概要間の有限のリソースを分割しているため、それ以外の場合は無意味です。 –

    +0

    あなたが「大きな」テーブルと言うときは、どういう意味ですか?行の数?データのサイズ?データベース全体と比較して?お返事ありがとうございます –

    +0

    > 100ギガバイトと数十億行の通常。 – gbn

    関連する問題