0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Oracle 9i のアーキテクチャ図は 26ai でどこまで通用するか

0
Last updated at Posted at 2026-08-05

この記事について

2002 年の Oracle 9i 研修教材に載っているアーキテクチャ図を眺めていて、ふと気になりました。この図は現行の 26ai でどこまで通用するのか、と。

結論から言うと、骨格はほぼそのまま通用します。SGA の中核プール、5 つの必須バックグラウンドプロセス、3 種のファイル構成は健在です。25 年前の図が今も教材として成立してしまうあたりが、Oracle アーキテクチャの安定性を物語っています。

ただし、その骨格の外側には確実に構造が足されています。本記事では変化を 5 点に整理し、9i 世代の知識のうち 何がそのまま使えて、何を読み替える必要があるか を切り分けます。

本記事の 26ai の記述は公式ドキュメントおよび Oracle Blogs の公開情報に基づきます。9i 側は当時の研修コース(DBA Fundamentals I)で扱われていた範囲を前提にしています。

oracle 9i 構成図
image.png

変化 1: データベースが入れ子になった

最大の構造変化です。9i は「1 インスタンス = 1 データベース」で、インスタンスは常にただ 1 つのデータベースをオープンしました。26ai では、インスタンスが対応するのは CDB(コンテナデータベース) ひとつで、業務データはその中の PDB(プラガブルデータベース) に入ります。

ここで最も誤解されやすい点を強調しておきます。

PDB を 10 個作っても、SGA とバックグラウンドプロセスは 1 組のままです。

バッファキャッシュも共有プールも REDO ログバッファも CDB レベルの資源であって、PDB ごとには存在しません。「PDB を追加する」はメモリとプロセスを増やす操作ではなく、既存の 1 インスタンスに間借りさせる操作です。

この方式は 12c(2013 年)で導入され、21c で非 CDB 構成が廃止されました。26ai もこれを引き継いでいるため、いま新規に作るデータベースは必ず CDB になります。9i 教材にある「データベースを作る」という手順は、26ai では「CDB を作り、その中に PDB を作る」に置き換わります。

26ai では PDB に設定した優先度を参照する操作が増え、重要な PDB を優先的に扱えるようになりました。メモリ面では sga_target を PDB 単位で調整できる一方、processes は CDB 全体でしか設定できず、全 PDB で総数を分け合います。

変化 2: SGA に新しいプールが増えた

9i の図に描かれていたプールは、すべて現役です。そのうえで追加されたものがあります。

コンポーネント 状態 26ai での位置づけ
Shared Pool 不変 ライブラリキャッシュとディクショナリキャッシュの構成も役割も同じ
Database Buffer Cache 不変 KEEP / RECYCLE、複数ブロックサイズ用サブキャッシュも 9i のまま
Redo Log Buffer 不変 循環バッファ。LGWR が書き出す仕組みも同じ
Large Pool / Java Pool 不変 任意プールという位置づけも同じ
In-Memory Column Store 12c で追加 列指向でメモリ上に保持し分析系を高速化。INMEMORY_SIZE
Vector Memory Pool 23ai で追加 AI Vector Search 用。VECTOR_MEMORY_SIZE

26ai では AI Vector Search が追加費用なしの標準機能になりました。ベクトル検索用のメモリプールが SGA の一員として常設される、というのが 9i 世代から見たときの一番の見た目の変化かもしれません。

変化 3: メモリ設計が手作業から自動へ

9i の目玉は「動的 SGA」でした。インスタンスを止めずにプールを増減できる、という触れ込みです。裏を返せば プールごとに DBA がサイズを決めるのが前提だったということでもあります。

その作業は現在ほぼ不要です。

時代 設定する対象 DBA がやること
9i DB_CACHE_SIZE / SHARED_POOL_SIZE / LARGE_POOL_SIZE … プールごとに個別に見積もって指定
10g〜 SGA_TARGET SGA 総量だけ決める。プールへの配分は自動(ASMM)
11g〜 MEMORY_TARGET SGA と PGA の境界すら自動(AMM)
26ai 上記 + PDB 単位の sga_target PDB 間の資源配分を設計する

さらに 26ai は内部で AI を用いて実行計画を改善し、リソース使用量を下げる方向に進んでいます。

なお PGA 側の PGA_AGGREGATE_TARGET は 9i で登場した仕組みで、これはそのまま主流であり続けています。9i 教材の該当箇所は今でも有効です。

変化 4: プロセスが増え、役割が分割された

9i の図には 6 個しか描かれていませんが、現在は数十〜100 を超えます。単に数が増えただけでなく、既存プロセスの仕事が切り出された点が実務上は重要です。

プロセス 状態 備考
DBWn 不変 ダーティバッファの書き出し
LGWR 不変 ただし LGnn ワーカーによる並列書き出しが加わった
CKPT / SMON 不変 チェックポイント情報の記録、インスタンスリカバリ
PMON 役割変更 12c 以降、障害プロセスのクリーンアップ実務は CLMN と CLnn ワーカーへ移管。PMON は監督役に
VKTM 追加 時刻管理
MMON / MMNL 追加 AWR 統計の収集
LREG 追加 リスナーへのサービス登録(9i では PMON の仕事だった)
SMCO / Wnnn 追加 領域管理タスクの自動実行

「PMON がプロセスの後始末をする」は 9i 教材の頻出項目ですが、現在その実務は CLMN / CLnn が担っています。トラブルシュート時にプロセス一覧を見る場面では、この差が効いてきます。

変化 5: ストレージと UNDO

  • ASM(10g〜) — OS のファイルシステムに代えて Oracle 自身がボリューム管理を行う構成が一般的になりました。9i 教材にある OFA(Optimal Flexible Architecture)に沿ったディレクトリ設計は、ASM 環境では出番がありません。
  • ローカル UNDO(12.2〜) — 9i では UNDO 表領域はデータベース全体で 1 つでしたが、現在は PDB ごとに持つのが既定です。
  • Exadata / Autonomous — これらの環境では物理ストレージそのものが抽象化され、DBA が直接触らない領域になります。

26ai そのものの位置づけ

  • 23ai を置き換える長期サポート(LTS)リリース。 2025 年 10 月 14 日に発表され、Linux x86-64 のオンプレミス版が提供開始されています。
  • 300 を超える新機能。焦点は AI と開発者生産性です。
  • AI Vector Search、多モデルデータ(リレーショナル / グラフ / JSON)、自律エージェント機能を統合した「AI ネイティブなコンバージドデータベース」という位置づけ。
  • Apache Iceberg 形式に対応した Autonomous AI Lakehouse。
  • 23ai からの移行は 2025 年 10 月の Release Update を適用するだけで、データベースのアップグレードもアプリケーションの再認証も不要です。

結論: 9i の知識はどこまで使えるか

そのまま通用するもの

  • インスタンスとデータベースの区別、起動 3 段階(NOMOUNT / MOUNT / OPEN)
  • SGA・PGA の各構成要素と役割
  • DBWn / LGWR / CKPT / SMON の動作契機
  • 記憶域階層(表領域 → セグメント → エクステント → ブロック)
  • UNDO と読取り一貫性の仕組み
  • B*Tree 索引とビットマップ索引の使い分け
  • 制約の 4 状態(ENABLE/DISABLE × VALIDATE/NOVALIDATE)と遅延チェック
  • 制御ファイル・オンライン REDO ログの多重化

読み替えが必要なもの

  • マルチテナント — 非 CDB は選べない。最優先で学ぶべき差分
  • ディクショナリ管理表領域(廃止済み)
  • 手動 UNDO 管理 / ロールバックセグメント(廃止済み)
  • プールごとの手動サイズ指定(自動化)
  • PMON のクリーンアップ責務(CLMN / CLnn へ)
  • UNDO 表領域は PDB ごと(ローカル UNDO)
  • OEM のクライアント / サーバー型コンソール(Cloud Control へ)

古い教材だからと捨てる必要はありません。アーキテクチャの土台を学ぶ用途では今も十分に機能します。その上に、マルチテナントという一枚の層を乗せるのが最短経路だと思います。

参考

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?