Oracle 8i がリリースされて以来、私はかなり長い間 Oracle を使用してきました。当時、私はデータベースに慣れていなかったので、テーブルスペースを定義するときは一定サイズのエクステント サイズを使用するのが最善であると教えられました。
私が読んだところによると、現在 10/11g を使用している場合、Oracle はこれらのエクステント サイズを自動的に管理でき、エクステント サイズを一定に保てない可能性があるようです。これがどのようにディスク容量をより効率的に使用できるかは簡単にわかりますが、これには欠点があります。これで過去を手放す時が来たのではないかと思います。（そもそも私の過去の教えが正しかったと仮定して）
はい、非常にまれなケースを除いて、過去を手放し、新しい Oracle エクステント管理機能を使用する時が来ました。ローカル管理テーブルスペース (LMT) と自動エクステント サイズ設定を使用すれば、このことについて再度考える必要はありません。
DBA として、最初は可変エクステント サイジングが心配でした。なぜなら、7.3 日間、テーブルスペースの再編成に多くの時間を費やして、0 以外のパーセントで増加するエクステント割り当てによる断片化を排除したからです。(また、エクステントの最大数は、データベース作成時に使用したデータベース ブロック サイズに応じてさまざまなレベルで制限されていたため、ゼロ以外のパーセントの増加が必要でした)。断片化を効果的に排除します。
また、テーブルまたはインデックスを 1 つのエクステントに収めるのが最適な構成である、またはエクステント構成を通じて何らかの方法で I/O を管理できるということについて聞いたことは忘れてください。これは決して真実ではありません。ディクショナリ管理のテーブルスペースの時代には、ディクショナリ テーブルで数千のエクステントを管理することにはおそらく何らかのペナルティがありましたが、LMT ではビットマップが使用されており、これは問題ではありません。Oracle は、セグメント エクステントではなく、ブロックをバッファします。
瞬時にアクセスできる無制限のディスク容量がある場合は、エクステントをまったく気にする必要はありません。
すべてのテーブルINITIAL 100T NEXT 100T MAXEXTENTS UNLIMITED PCTINCREASE 0を作成し、次の年のエクステントを忘れるだけ300です。
この問題は、ディスク容量が無制限でない場合やアクセス時間が異なる場合に発生します。
エクステントは、データのまばらさに対処することを目的としています。データが断片化されると、HDD頭をある場所から別の場所にジャンプすることになり、時間がかかります。
理想的な状況は、各テーブルのすべてのデータを1つのエクステントに配置し、最も頻繁に結合するテーブルのデータを次のエクステントに配置して、すべてを順番に読み取ることができるようにすることです。
アクセス時間には、データがどこにあるかを把握するために必要なアクセス時間も含まれることに注意してください。データが非常にまばらな場合は、エクステントディクショナリをさらに検索する必要があります。
現在、ディスク容量は重要ではありませんが、アクセス時間は依然として重要です。
そのため、Oracleエクステント管理が作成されました。
これは、手作りのエクステントレイアウトよりも使用されるスペースの点では効率的ではありませんが、アクセス時間の点ではより効率的です。
したがって、十分なディスク容量がある場合（つまり、データベースが何年もの間ディスクの半分未満5しか使用しない場合）、自動エクステントを使用するだけです。