物理階層の全体像

RDBMSはディスクを以下のような階層で管理しています。

  • Block（ブロック）: I/Oの最小単位。4K/8K/16Kなど。1ブロックに複数行が入る。
  • Extent（エクステント）: 連続するブロックのまとまり。セグメントが大きくなる度に確保。
  • Segment（セグメント）: テーブル / インデックス / LOBごとの論理的なまとまり。
  • Tablespace（表領域）: 1つ以上のデータファイルから成る論理的な格納先。

ブロック → エクステント → セグメント → 表領域

用途別に表領域を分けるのが一般的です。

  • USERS: 業務データを格納
  • INDEX: インデックス専用
  • TEMP: 一時表領域（ソートなど）
  • UNDO: ロールバック領域
  • SYSTEM: 辞書情報
  • LOB: 大きなオブジェクト用

データファイル / REDOログ / 制御ファイル

データファイル

実データ・インデックスの実体。

  • 表領域 = 1つ以上のデータファイルの集合
  • 更新は基本「バッファキャッシュ → DBWR → ファイル」

REDOログ

変更履歴を時系列で記録。

  • コミット時にLGWRが必ず書き出す
  • 障害時はREDOを再適用してリカバリ

制御ファイル

DB全体の構成情報・状態。

  • データファイル/REDOログのパスやSCN
  • 破損するとマウント不可 ⇒ 必ず多重化

アーカイブログ

満杯になったREDOの退避コピー。

  • アーカイブモード時のみ
  • PITR（指定時点復旧）に必須

UNDO（ロールバック領域）

更新前のイメージを保管。

  • ROLLBACK / 一貫性読み取りで利用
  • トランザクションが長いとUNDOを圧迫しやすい

一時（TEMP）

ソート/作業領域の溢れ先。

  • PGAで処理しきれない場合の退避
  • 後の章で詳述

バッファキャッシュとI/Oの流れ

  • SELECT は必要なブロックをファイルから読み、バッファキャッシュに乗せる（キャッシュヒットしなければ物理I/O）。
  • UPDATE はバッファキャッシュ上のブロックを書き換える + REDOログバッファに変更履歴を残す。
  • 実ファイルへの書き出しは DBWR が後でまとめて行う（= ユーザは待たない）。
  • コミット時には REDO が必ずディスクに書かれる ⇒ そこで初めて「永続化された」と言える。
バッファキャッシュ上の状態:
  • Dirty: 変更あり、未書き出し
  • Clean: ディスクと同一