Oracle データベースを新規に作成すると、何も設定していなくても
いくつかの 「事前構成済の表領域」 が自動的に作られます。
これらは Oracle 本体の管理情報や、一時的な処理用領域、
一般ユーザーが使うためのデフォルト領域など、
データベース運用の土台になる重要な領域 です。
この記事では、Oracle が作成時に自動で用意してくれる主な表領域と、
それぞれがどのような役割を持っているのかを整理して解説します。
表領域とは何か？
まず前提として、表領域（tablespace） のイメージを簡単におさらいしておきます。
-
データベース内の 論理的な「入れ物」
-
実体は 1 つ以上の データファイル（*.dbf など）
-
テーブルやインデックスなどのセグメントは、どこかの表領域に属して保存される
つまり、表領域は
「どの種類のデータを、どの物理ファイル群に格納するか」
を切り分けるための単位、と考えると分かりやすいです。
事前構成済の表領域
Oracle データベースを作成すると、デフォルトで次のような表領域が自動作成されます。
表領域 説明 SYSTEM Oracleサーバーがデータベースを管理するために使用する表領域 SYSAUX SYSTEM表領域の補助表領域 TEMP データベースのデフォルトの一時表領域 UNDOTBS1 UNDO表領域 USERS 永続表領域
SYSやSYSTEMユーザー以外のユーザー用のデフォルト表領域EXAMPLE データベース作成時に「サンプル・スキーマの作成」を指定すると作成される表領域
各表領域の役割をもう少し詳しく
上の表だけだと、ニュアンスがつかみにくい部分もあるので、
代表的な表領域について、もう少し踏み込んで解説します。
SYSTEM 表領域
-
Oracle データベースの 中枢となる管理情報 が格納される領域
-
データディクショナリ（オブジェクト定義情報など）が含まれる
-
原則として、アプリケーションのユーザーデータを入れるべきではない
SYSTEM をいっぱいにしてしまうと、
データベース全体がまともに動作しなくなる 危険があるため、
運用設計時点で「SYSTEM には触らない」というルールを決めておくことが多いです。
SYSAUX 表領域
-
SYSTEM 表領域の 補助表領域
-
さまざまなコンポーネント（Enterprise Manager など）の管理情報が格納される
-
Oracle 10g 以降で導入された、比較的新しい位置づけの表領域
SYSAUX は SYSTEM の負荷分散のために存在しているので、
こちらもアプリケーション用のオブジェクトを作成する場所ではありません。
TEMP 表領域
-
ORDER BY、GROUP BY、ソート、ハッシュ結合などの際に使われる
一時的な作業領域 -
メモリに収まらなかったデータの「一時退避先」になる
TEMP が足りないと、次のような影響が出ます。
-
大量データを扱う SQL の性能劣化
-
場合によってはエラー（ORA-01652 など）で処理失敗
大量データ処理を行うシステムでは、
TEMP のサイズと使用状況を定期的に監視する運用 がほぼ必須です。
UNDOTBS1（UNDO 表領域）
-
更新系処理の ロールバック情報（UNDO） を保存する表領域
-
トランザクションの取り消しや、一貫性のある参照（CONSISTENT READ）で利用される
UNDO が足りなくなると、
-
ロングトランザクションで古い UNDO が上書きされてしまう
-
一貫性の保証ができなくなり、エラーが発生する
といった問題に繋がります。
特にバッチ処理など、長時間走る大量更新 があるシステムでは、
UNDO 表領域のサイズ設計が重要です。
USERS 表領域
-
一般ユーザーがオブジェクトを作成するための デフォルト表領域
-
SYS / SYSTEM 以外のユーザーに割り当てられることが多い
小規模環境や検証用データベースでは、
「とりあえず USERS に全部作る」という運用もよくありますが、
本番環境では業務ごとに表領域を分割したり、
表とインデックスで表領域を分けるなどの設計を行う場合もあります。
EXAMPLE 表領域
-
データベース作成時に「サンプル・スキーマを作成する」を選んだ場合のみ作成される
-
サンプルスキーマ（HR, OE など）のオブジェクトが格納される
学習・検証用途には便利ですが、
本番環境では不要なことが多く、
作成しない or 不要であれば削除する といった扱いにするケースが一般的です。
実運用で意識しておきたいポイント
事前構成済の表領域は、
「最初からあるからそのまま使う」だけだと、
後から運用で困ることもあります。
実務では、特に次の点を意識しておくとトラブルを避けやすくなります。
1. SYSTEM/SYSAUX にユーザーデータを入れない
-
管理系の表領域に業務テーブルを作らない
-
開発時点で デフォルト表領域を USERS などに変更 しておく
2. TEMP と UNDO のサイズを定期的に確認する
-
大量データを扱うバッチ処理の前後で使用量をチェック
-
苦しくなってきたら、表領域の追加・拡張 を検討
3. USERS を「なんでも置き場」にしない
-
システムが大きくなる前に、業務単位で表領域を分ける設計を検討
-
バックアップ／リストア単位としても表領域分割は有効
まとめ
Oracle データベースを作成すると、
SYSTEM / SYSAUX / TEMP / UNDOTBS1 / USERS / EXAMPLE などの
事前構成済の表領域 が自動的に作成されます。
これらはそれぞれ、
-
データベース管理情報の領域
-
各種コンポーネントの補助領域
-
ソートや一時処理用の領域
-
ロールバック情報（UNDO）用の領域
-
一般ユーザー用のデフォルト領域
-
サンプルスキーマ用の領域
といった役割を持っており、
闇雲に使ってよい領域と、そうでない領域がはっきり分かれている のがポイントです。
開発や運用の現場では、
-
SYSTEM / SYSAUX にアプリのテーブルを作らない
-
TEMP / UNDO の使用状況を監視する
-
USERS を一時しのぎではなく、きちんと設計する
といった点を意識しておくと、
後からの障害対応やパフォーマンス劣化に悩まされにくくなります。
