システム表領域、UNDO表領域、一時表領域は独立した表領域として作成して下さい。また、これらの表領域にはユーザーのテーブルやインデックスは作成しないようにして下さい。

OMFは表領域の自動管理を目的とする機能です。OMFの詳細につきましては第1部の第5章「OMF構成の紹介」を参照してください。

読取専用のテーブルやインデックスは読取専用の表領域に格納します。読取専用表領域に格納することで、読取専用であることが明示的にわかるようになります。また、一度バックアップを取れば、更新がないので定期的にバックアップを取る必要がなくなります。テーブルやインデックスをパーティション化してパーティション毎に表領域を分けると、更新されることのないパーティションのみ読取専用とすることもできます。

例えばテーブルとインデックスは別々の表領域に格納する、あるいは同じテーブルでも通常のテーブルとLOBテーブルは別々の表領域に格納する、といったように、オブジェクトごとに表領域を分けます。DB規模が大きいほど、後々の管理がやりやすくなります。

例えばSCOTTユーザー所有のオブジェクトとSMITHユーザー所有のオブジェクトは別々の表領域に格納する、といったように、オブジェクト所有ユーザーごとに表領域を分けます。DB規模が大きいほど、後々の管理がやりやすくなります。

例えば経理システムで使用するオブジェクトと人事システムで使用するオブジェクト、両方で使用するオブジェクトは別々の表領域に格納する、といったように、業務ごとに表領域を分けます。DB規模が大きいほど、後々の管理がやりやすくなります。

大容量のディスクを少量用意するよりも、小容量のディスクを大量に用意し、極力データを分散させることで、障害の影響を小さくするという意味で耐障害性を確保することができます。もっとも、ディスクの大容量化によってこの対策をとることは難しいかもしれません・・・

同一ディスク上でパーティション、ディレクトリ、ファイルといった単位で分けることも、ディスクを分割することに比べれば効果は小さいですが、障害範囲の極小化などといった効果はあります。

あまりあるケースではないと思いますが、DB内のデータの重要度に極端な差があり、その割にディスクに割ける予算が限られている場合は、重要なデータはRAID構成のディスク装置に表領域を配置し、そう重要でないデータはRAIDでないディスク装置に表領域を配置するといった手も考えられます。

インデックスを介したスキャンが実行される場合、同じディスクにテーブルとインデックスがあると、テーブルとインデックスの間のHDDのアームの移動が頻繁に発生します。検索対象レコード数が多いほどパフォーマンスの影響が出てきます。

結合方法により差がありますが、結合対象のテーブル同士の間のアームの移動が頻繁に発生します。検索対象レコード数が多いほどパフォーマンスの影響が出てきます。

パラレル処理は複数のプロセスを立ち上げて、各プロセスが同じテーブルやインデックスにアクセスするため、同じディスクに配置しているとI/Oの競合が発生し、却ってパフォーマンスが落ちることがあります。セグメントに対して複数のデータファイルを作成するか、パーティション化してデータファイルを分けるなどして、別ディスクに配置するようにしてください。

システム表領域はその他の表領域、REDOログファイルとは異なるディスクに配置するようにして下さい。特にオブジェクト数の多いシステム、監査証跡をテーブルに記録するシステム、マルチマスタ・レプリケーションやアドバンスド・キューイングを利用するようなシステムではシステム表領域へのI/Oが多発します。システム表領域へのI/Oが多発するような場合、システム表領域自体を複数のデータファイルで作成し、データファイルを分散させると有効です。

UNDO表領域はその他の表領域、REDOログファイルとは異なるディスクに配置するようにして下さい。特に更新処理の多いシステムではUNDO表領域へのI/Oが多発します。UNDO表領域へのI/Oが多発するような場合、UNDO表領域自体を複数のデータファイルで作成し、データファイルを分散させると有効です。

一時表領域はその他の表領域、REDOログファイルとは異なるディスクに配置するようにして下さい。特に大量ソート処理の多いシステムでは一時表領域へのI/Oが多発します。一時表領域へのI/Oが多発するような場合、一時表領域自体を複数のデータファイルで作成し、データファイルを分散させると有効です。一時表領域の場合は一時表領域そのものを複数作成し、ユーザーによって利用する一時表領域を分けるという方法もあります。

ディクショナリ管理表領域ではエクステント管理はシステム表領域で集中して行います。エクステントの追加や削除の処理はディクショナリに対するI/Oがかなり多いため、このような処理が頻発するとパフォーマンスに大きな影響が出ます。一方ローカル管理表領域はエクステント管理を各表領域で行うため、システム表領域へのI/Oは最小限に抑えられます。また、ディクショナリの更新はUNDOの生成を伴いますが、ローカル管理表領域のビットマップの更新はUNDOをほとんど生成しません。ローカル管理表領域ではディクショナリ管理表領域に比べ以下のような処理が高速になります。

• エクステントの拡張
• UNDOセグメントを利用する処理（更新系SQL等）
• TRUNCATE
• セグメントのDROP

ローカル管理表領域ではエクステント管理方法の変更に伴い、エクステント管理の為のパラメータが削減されています。そのため、設計・管理が楽になります。また、エクステント確保の方法が単純になるため、その点でも管理が楽になります（詳細は（3）を参照）。ローカル管理表領域においてCREATE/ALTER TABLESPACE文で指定不要になったパラメータは以下の通りです。

• DEFAULT STORAGE句
• MINIMUM EXTENT
• TEMPORARY

CREATE/ALTER TABLE、CREATE/ALTER INDEXのパラメータについては次回以降に解説します。

ローカル管理表領域ではエクステント確保のロジックが2種類用意されています。ひとつはデフォルトのAUTOALLOCATE指定で、セグメントサイズに従い64KB, 1MB, 8MB, 64MBのエクステントをOracleが自動で確保します。もうひとつはUNIFORM指定で、CREATE TABLESPACE時に指定した固定サイズでエクステントを確保します。AUTOALLOCATE指定の際は少数の、UNIFORM指定の際はひとつのサイズのエクステントしか作成されないため、エクステント・レベルで未使用になる領域の発生が抑えられます。

ディクショナリ管理表領域では連続した空きエクステントをひとつの大きなエクステントに結合するためにコアレス（coalesce）という処理が必要でした。しかしローカル管理ではコアレスしなくても連続した空きエクステントを認識することができます。

ダイレクト・ロードやダイレクト・ロード・インサートといった処理は、データを一旦一時セグメントに書き込み、実際に書き込んだ大きさにて一時セグメントをテーブルないしインデックスのエクステントに変換することが高速化の一要因になっています。しかしローカル管理表領域はエクステントサイズが決まっているため、実際に書き込んだ大きさではなく決まった大きさで一時セグメントを作成しないといけないため、エクステントのフォーマッティングに関するロスが発生します。遅くなるといってもディクショナリ管理表領域に比べて遅いだけで、ローカル管理表領域上の従来パスよりは大幅に高速です。

管理が簡単になる反面、テーブルやインデックスに必要な大きさにぴったりのエクステント・サイズを個別指定することができにくくなります。ディクショナリ管理表領域で必要容量をきっちり決めて管理した場合に比べると、エクステント内の未使用領域は増えがちになります。

以下の手順で見積もります。

1. データファイルに格納するテーブルやインデックスの見積合計サイズに余裕値を加えた値を算出します。テーブルやインデックスの見積については次回以降で解説の予定です。
2. 1.の値を、AUTOALLOCATE指定の場合は64KBの倍数に、UNIFORM指定の場合はUNIFORM SIZEの倍数になるように切り上げます。
3. 2.の値に表領域のヘッダとエクステント管理用のビットマップの領域として64KBを加えてください。

余裕値が十分な値であれば、2.や3.を行う必要はありませんが、この計算方法だとデータファイルが目一杯利用された時にファイルの最後に無駄な空きができません。もっとも昨今のディスク容量であれば数MBレベルの無駄があっても問題にならないと思われるので、計算が面倒であれば1.の計算だけでも十分でしょう。

AUTOALLOCATE指定はセグメント・サイズに応じたエクステントを自動で割り当てるため、UNIFORMに比べて領域が効率的に利用できます。一方エクステントサイズが何種類かになるため、エクステントの追加・開放を繰り返すうちに、エクステント間に利用できない断片化領域が発生する可能性があります。一方UNIFORM指定はエクステントサイズが固定なので非常にわかりやすいという利点があります。領域の効率的な利用については、UNIFORM SIZEの調整でそれほど無駄は出なくなります。また、UNIFORM指定は（1）の方法でサイズを設定するとエクステント・レベルでの未使用領域の断片化は発生しません。基本的にUNIFORM指定を利用することをお勧めします。AUTOALLOCATE指定は領域の指定がルーズであっても構わないと判断できるシステム（小規模システムや開発機のDBなど）、少量データ用の表領域などにお勧めです。

基本的に自動拡張（AUTOEXTEND句）に頼るのはよくないことです。自動拡張をONにすると、ファイルのレベルで断片化が発生する可能性がありますし、何らかのSQL処理中のデータファイルの拡張は負荷が高い処理となります。データファイルとして必要な容量をきちんと見積もり、自動拡張が発生しないようにしましょう。ただ、見積をきちんとやった上で保険として設定しておくのは悪いことではありません。その際の拡張サイズはあまり頻繁に拡張が発生しないような値にしておいたほうがいいです。

設計や管理が難しいロールバック・セグメントについてほとんど何も考えなくてもいいというのは、DBAの方にとっては非常に魅力が大きいと思われます。自動UNDOで設計しないといけないのは表領域の名前とデータファイルの容量、初期化パラメータUNDO_RETENTIONの値(後述)、初期に作成するUNDOセグメントの数（基本はOracleで自動計算）のみです。

ある程度経験のあるDBAの方であれば、一度は大量更新処理におけるORA-01555の発生に悩まされたことがあるかと思います。大量更新処理におけるORA-01555は読み取り一貫性の為に確保されたUNDOセグメント上のデータが他のトランザクションで上書きされてから、そのデータへの参照要求が来た時に発生します。自動UNDO管理にすると初期化パラメータUNDO_RETENTIONで設定した期間中はUNDOデータが上書きされずに残るため、ORA-01555が発生しにくくなります。

自動UNDO管理にすると、あるUNDOセグメントがUNDO表領域の残り領域を使い切って表領域の拡張も出来ない場合、他のUNDOセグメントに空きがあればその空きを未使用領域として開放させ、処理を継続させます。手動UNDO管理で同様の状況に陥った場合は他のロールバック・セグメントに空き領域があったとしても領域不足エラーになります。

フラッシュバック・クエリーとは、コミットされた過去のデータを遡って見ることができるOracle9i新機能です。誤ってデータを更新してコミットしてしまった場合のリカバリに便利な機能です。手動UNDO管理でもこの機能は利用できるのですが、過去のデータ保存期間が保証されません。つまり過去のデータを見ることができるかどうかは運次第になります。自動UNDO管理にすると初期化パラメータUNDO_RETENTIONを指定できるようになり、このパラメータに設定した時間内はUNDOデータが保存されやすくなります。最終的にUNDO表領域が逼迫した場合は自動UNDO管理でも過去のUNDO情報を格納した領域を使用するのですが、自動UNDO管理にした方が手動UNDO管理に比べ、過去のUNDO情報が残りやすくなります。

テンポラリファイルを利用した専用一時表領域はREDOログを生成しないので、他のタイプの一時表領域に比べ非常にパフォーマンスに優れます。

テンポラリファイルを利用した専用一時表領域はバックアップの対象外にできますので、その分バックアップが高速になります。テンポラリファイルを利用した専用一時表領域のリカバリはバックアップを戻すのではなく作り直しで対応します。