データベースオブジェクトを異なるテーブルスペースに分離することのパフォーマンス上の利点は何ですか？
質問が述べているように、次の情報/制約を前提として、これを行うことの利点は何ですか？
- パーティショニングは使用しません
- 表領域とそのデータファイルを別のハードディスクドライブに配置することはありません
- 私のスキーマにはたくさんの（おそらく約50から100の）小さなテーブルがあり、レコード数の点で大きくなるのは約5から10のテーブルだけです。
- これらの5〜10個のテーブルの予想される増加は、最大10万行に達する可能性がありますが、おそらく100万行には達することはありません。
これらの大きなテーブルを、残りのテーブルとインデックスに使用されるテーブルスペースと混合するのではなく、独自のテーブルスペースに分離することを計画しています。また、すべてのインデックスを別のテーブルスペースに配置することを計画しているため、ユーザーが使用するテーブルスペースのリストは次のようになります。
- Tablespace_BIG_Table_1 ... 10
- Tablespace_for_indexes
- Tablespace_for_the_rest_of_the_tables
表領域を「きちんと整理」する以外に、パーティショニングを使用せず、単一のディスクのみを使用し、さらに比較的少数のレコードセットのみを使用している場合、これから得られるパフォーマンス上の利点はありますか。 ？
または、すべてを単一のテーブルスペースに配置することに固執する必要がありますか？
パフォーマンス上のメリットは最小限ですが、この点での唯一のメリットは、断片化の減少によるものです。しかし、Oracleとほとんどのファイルシステムは、これを以前よりもはるかにうまく処理しています。 Oracleは、「自動セグメントスペース管理」とOracleの「ファイルシステム」ASMを使用してこれをより適切に処理しますが、後者を使用する必要はありません。
最近では、管理しやすさの選択が増えています。個人的には、個別のテーブルスペースを気にすることはありませんが、アプリケーションごとに1つ作成することがよくあります。これにより、必要に応じて、トランスポータブル表領域のエクスポートを使用できます。
インデックスはテーブルとは異なる方法で「成長」します。また、（さまざまな理由で）インデックスを再構築すると、テーブルスペースが簡単に断片化する可能性があります。これらを別々に保管することは常に良い考えです。
また、均一なエクステント割り当てを使用する場合、少なくとも小さなテーブル（参照、列挙、LOV）およびターゲットテーブルのテーブルスペースに設定するオプションは他にありません。