新人エンジニアからDBの仕組みを一から聞かれるたびに、自分の説明がバラバラになっていることに気づきました。全体像を一枚の地図として説明できるよう、このシリーズの出発点としてまとめています。

RDBMSとは

RDBMSアーキテクチャ概要図

図1: RDBMSの内部構成（SQLパーサ・オプティマイザ・実行エンジン・メモリ構造）

RDBMS = Relational Database Management System。データを「行」と「列」を持つ表（テーブル）として管理する仕組みです。

  • テーブル同士をキーで関連付け（リレーション）、整合性を保ちながら検索・更新できる。
  • ユーザは SQL（宣言型言語）で要求を伝え、DBエンジンが最適な実行方法（実行計画）を選ぶ。
  • 複数ユーザの同時アクセスを安全に処理するため、トランザクション と ロック を備える。
  • 障害から復旧するために REDO/UNDO といったログ機構を持つ。

RDBMSが担うこと

  • SQL 解析・最適化
  • 実行・データ取得
  • 同時実行制御（Lock）
  • 永続化と障害回復（REDO/UNDO）
  • セキュリティ・監査

クライアント・サーバ構成

アプリ（クライアント）はネットワーク経由でDBサーバに接続し、SQLを送って結果を受け取ります。

  • 接続はTCP上のDB専用プロトコル（Oracle Net / PG wire / TDS / DRDA など）
  • 1接続 ≒ 1セッション（1サーバプロセス/スレッド）
  • 接続コストは大きい ⇒ 必ずコネクションプール
アプリ ↔ DBの間に「リスナー」がいて、接続要求をサーバプロセスへ取り次ぐイメージ。
// 概念図
App (Client) ──SQL──> Listener ──> Server Process
                                       │
                              ┌────────┴────────┐
                              │ DB Server (Instance) │
                              │  SGA (共有メモリ)       │
                              │   ├ Buffer Cache       │
                              │   └ REDO Buffer        │
                              │  Background Processes  │
                              └────────┬────────────────┘
                                       ↓
                          Storage (データファイル/ログ/制御)

インスタンスとデータベース

インスタンス (Instance) = メモリ + プロセス群

  • サーバ起動時に確保される共有メモリ領域と、それを利用するDBエンジンのプロセス集合。
  • SQLの解析、キャッシュ管理、ログ書き出し、チェックポイントなどはここで動く。
  • 再起動すると揮発する状態（メモリ・キャッシュ）。
  • 1台のサーバに複数インスタンスを動かすことも可能。

データベース (Database) = ディスク上のファイル群

  • データファイル / 制御ファイル / REDOログ等のディスク上の永続データの集合体。
  • インスタンスを停止しても消えない（永続）。
  • 1つのDBに対し、複数インスタンスから接続する構成（RAC/共有DBクラスタ）も存在する。
  • バックアップとリストアの単位もこのレイヤ。
POINT　「データベースを止めた」と言うとき、実は「インスタンスを止めた」だけのことが多い。

メモリ構造（共有メモリとセッションメモリ）

共有メモリ（SGA 相当）

  • Buffer Cache: テーブル/インデックスのブロックをキャッシュ。読み書きは原則このキャッシュ経由で行われる。
  • REDO Log Buffer: 更新変更履歴を一時的に保持。コミット時等にディスクのREDOログへ書き出される。
  • Shared Pool: SQLの解析結果（実行計画）、辞書情報、PL/SQLなどをキャッシュ。同一SQLの再利用効率に直結。
  • その他: Large Pool / Java Pool / 結果キャッシュなど、製品により様々。

セッション専用メモリ（PGA 相当）

  • 接続中のセッションごとに確保
  • ソート/ハッシュ結合の作業域
  • カーソル状態・バインド変数
  • 大きくなりすぎると一時表領域へ溢れる（Disk Sort / Spill to disk）⇒ パフォーマンスを大きく左右

バックグラウンドプロセス

インスタンスは表に出ない多くの常駐プロセスを内包します。代表的なものを以下に示します。

  • DBWR / Writer: バッファキャッシュ上の汚れたブロックをデータファイルに書き出す。
  • LGWR / Log Writer: REDOログバッファをオンラインREDOログに書き出す。コミットの中核。
  • CKPT / Checkpoint: 整合点を作成し、データファイルに「ここまで反映済」と記録。
  • ARCH / Archiver: 満杯になったオンラインREDOをアーカイブログへコピー（アーカイブモード時）。
  • SMON / System Mon: 再起動時のリカバリ、一時セグメントの解放など。
  • PMON / Process Mon: 異常終了したセッションのクリーンアップ、ロックの解放など。
プロセス名は製品により異なるが「役割」はほぼ共通です。

DB構造に関するよくある誤解

誤解実際の動作
「DBを停止した」＝データが消える インスタンス（メモリ・プロセス）が停止するだけで、データファイルはディスクに残る。データが消えるのは DROP TABLE や DELETE などの操作を行ったとき
コネクションプールを使えばDB接続コストはゼロ プール内の接続は再利用されるが、プール上限を超えると新規接続が発生しコストがかかる。プールサイズの適切な設定が必要
メモリを増やせばDBは速くなる Buffer Cache や Shared Pool のヒット率が低い場合はメモリ増加が有効だが、SQL自体が非効率な場合はメモリを増やしても効果は薄い
コミットするとすぐにディスクに書き込まれる コミット時にはREDOログ（LGWR）への書き込みが保証されるが、データファイルへの反映（DBWR）は非同期で後から行われる