web-dev-qa-db-ja.com

データベースオブジェクトを異なるテーブルスペースに分離することのパフォーマンス上の利点は何ですか?

質問が述べているように、次の情報/制約を前提として、これを行うことの利点は何ですか?

  1. パーティショニングは使用しません
  2. 表領域とそのデータファイルを別のハードディスクドライブに配置することはありません
  3. 私のスキーマにはたくさんの(おそらく約50から100の)小さなテーブルがあり、レコード数の点で大きくなるのは約5から10のテーブルだけです。
  4. これらの5〜10個のテーブルの予想される増加は、最大10万行に達する可能性がありますが、おそらく100万行には達することはありません。

これらの大きなテーブルを、残りのテーブルとインデックスに使用されるテーブルスペースと混合するのではなく、独自のテーブルスペースに分離することを計画しています。また、すべてのインデックスを別のテーブルスペースに配置することを計画しているため、ユーザーが使用するテーブルスペースのリストは次のようになります。

  • Tablespace_BIG_Table_1 ... 10
  • Tablespace_for_indexes
  • Tablespace_for_the_rest_of_the_tables

表領域を「きちんと整理」する以外に、パーティショニングを使用せず、単一のディスクのみを使用し、さらに比較的少数のレコードセットのみを使用している場合、これから得られるパフォーマンス上の利点はありますか。 ?

または、すべてを単一のテーブルスペースに配置することに固執する必要がありますか?

2
Avias

パフォーマンス上のメリットは最小限ですが、この点での唯一のメリットは、断片化の減少によるものです。しかし、Oracleとほとんどのファイルシステムは、これを以前よりもはるかにうまく処理しています。 Oracleは、「自動セグメントスペース管理」とOracleの「ファイルシステム」ASMを使用してこれをより適切に処理しますが、後者を使用する必要はありません。

最近では、管理しやすさの選択が増えています。個人的には、個別のテーブルスペースを気にすることはありませんが、アプリケーションごとに1つ作成することがよくあります。これにより、必要に応じて、トランスポータブル表領域のエクスポートを使用できます。

3
Colin 't Hart

インデックスはテーブルとは異なる方法で「成長」します。また、(さまざまな理由で)インデックスを再構築すると、テーブルスペースが簡単に断片化する可能性があります。これらを別々に保管することは常に良い考えです。

また、均一なエクステント割り当てを使用する場合、少なくとも小さなテーブル(参照、列挙、LOV)およびターゲットテーブルのテーブルスペースに設定するオプションは他にありません。

1
ibre5041