【Oracle】実際に触って学ぶBronze DBA(26ai)#1-3：データベース・ファイルの理解

Last updated at 2026-08-18Posted at 2026-08-18

はじめに

実機環境には Oracle AI Database 26ai Free（CDB=FREE / PDB=FREEPDB1）を使います。Vagrant + VirtualBox での構築手順は以下にまとめています。

実機環境: Oracle AI Database 26ai Free（CDB=FREE / PDB=FREEPDB1）。Vagrant + VirtualBox で構築しています。
環境構築がまだの方はこちらからどうぞ → Oracle AI Database 26ai Free を自分のPCに入れる（Vagrant版）
前々回 #1-1「RDB・SQL・重要用語」はこちら → 実際に触って学ぶBronze DBA(26ai)#1-1
前回 #1-2「インスタンスとデータベースのコンポーネント」はこちら → 実際に触って学ぶBronze DBA(26ai)#1-2

免責

この連載「実際に触って学ぶBronze DBA(26ai)」は、ORACLE MASTER Bronze DBA（Oracle AI Database 26ai / 1Z0-185-JPN）の試験範囲を題材に、実際に手を動かしながら理解を深めることを目的としています。

本連載は合格保証や試験対策そのものを目的とするものではありません。試験範囲を使い、その一つひとつを実機で確かめていく知識補完の記事、という位置づけです。

今回記事の範囲

第1章：Oracleデータベース管理の概要

リレーショナル・データベースおよびSQLの理解 … #1-1（済）
インスタンスおよびデータベースのコンポーネントの理解 … #1-2（済）
マルチテナント・コンテナ・データベースの利点の理解 … #1-4で解説予定
✅ データベース・ファイルの理解 … 今回
Oracleデータベースの管理に使用するツールの理解 … #1-1（済）
Oracleデータベースの重要な用語の理解 … #1-1（済）
Oracle AI Database 26aiの新機能の概要 … #1-5で解説予定
Oracle AI Database 26aiの特徴と利点 … #1-5で解説予定

前回（#1-2）の振り返り

前回は「インスタンスとデータベースのコンポーネント」を扱いました。

この連載ではインスタンス＝エンジン、データベース＝燃料タンクというたとえを使っています。#1-2では、そのうちの エンジン側 をボンネットを開けて解剖しました。SGA（共有プール、データベース・バッファ・キャッシュ、REDOログ・バッファ…）というメモリ領域と、DBWn・LGWR・CKPT・SMON・PMONといったバックグラウンド・プロセス。これらが揃って初めて「インスタンスが起動している」状態になる、という話でした。

#1-2：インスタンスとデータベースのコンポーネントの理解

そして今回は、もう一方の 燃料タンク側 、つまり ディスク上に置かれたファイル群 を開けていきます。

インスタンスは電源を切れば消えてしまいますが、ファイルはディスクに残ります。「データが消えない」というデータベースの当たり前を支えているのが、今回の主役です。

データベースは"3種類のファイル"でできている

まず結論から書きます。ここは試験でも頻出で、かつ実務でも一生使う整理です。

Oracleデータベースを構成する物理ファイルは、次の3種類です。

制御ファイル（control file）
データファイル（data file）
オンラインREDOログ・ファイル（online redo log file）

「あれ、SPFILEやパスワードファイルは？」と思われた方、鋭いです。それらは確かに重要ですが、データベースを構成するファイルではありません。この区別が今回いちばんのポイントなので、後半の「"DBの外側"のファイル」で改めて扱います。

3種類の役割をひとことで言うと、こうなります。

ファイル	役割	例え
制御ファイル	DBの構成情報を記録する	建物の管理台帳（どこに何があるかの目次）
データファイル	実際のデータを格納する	倉庫（荷物そのものが入っている）
オンラインREDOログ	変更内容を記録する	作業日誌の控え（何をしたかの記録）

CDB＝マンションの建物、PDB＝部屋というたとえを#1-2から引き継ぐなら、「管理台帳を見て、どの倉庫に何が入っているかを把握し、作業のたびに記録をつける」イメージです。

そして重要なのは、この3つのうち1つでも欠けるとデータベースは正常に開けないということ。倉庫（データファイル）だけあっても、台帳（制御ファイル）がなければどこに何があるか分かりませんし、日誌（REDOログ）がなければ障害時に「どこまで進んでいたか」を復元できません。

では、1つずつ見ていきましょう。

制御ファイル

制御ファイルは、マンションの管理台帳です。

この建物の名前は何か（データベース名、DBID）
倉庫（データファイル）は何番がどこにあるか
日誌（REDOログ）は何冊あって、いまどれを使っているか
最後に棚卸し（チェックポイント）をしたのはいつか
バックアップをいつ取ったか（RMANを使う場合）

こうした「データベースそのものの構成情報」が、小さなバイナリファイルにぎゅっと詰まっています。

サイズは数十MB程度と、データファイルに比べればごく小さいものです。しかし、これが失われるとデータベースは起動できません。台帳を失った管理人は、倉庫が目の前にあっても何がどこにあるか分からないわけです。

インスタンス起動の流れでいうと、NOMOUNT（インスタンスだけ起動）から MOUNT に進む段階で読み込まれるのが、この制御ファイルです。つまり MOUNT = 制御ファイルを開いた状態 と覚えておくと、あとの章がラクになります。

だからこそ、Oracleは制御ファイルの 多重化（multiplexing） を強く推奨しています。同じ内容のコピーを複数の場所に持っておき、1つ壊れても他で運用を続けられるようにする、という考え方です。

実機ラボで確認

まずは環境への接続から。Vagrant + VirtualBox で構築された方は、ホストOSのターミナルから次のように入ります。

vagrant ssh
sudo su - oracle
sqlplus / as sysdba

接続できたら、いま自分がどこにいるかを確認しておきましょう。

SHOW CON_NAME
SELECT name, open_mode, cdb FROM v$database;

出力例：

CON_NAME
------------------------------
CDB$ROOT

NAME      OPEN_MODE            CDB
--------- -------------------- ---
FREE      READ WRITE           YES

CDB$ROOT にいること、CDB 列が YES（＝これはマルチテナント構成のCDB）であることが分かります。以降のSQLはすべてCDBルートにSYSDBAで接続した状態で実行します。

では制御ファイルを見てみます。

SELECT name FROM v$controlfile;

出力例：

NAME
------------------------------------------------------------
/opt/oracle/oradata/FREE/control01.ctl
/opt/oracle/oradata/FREE/control02.ctl

2つありますね。これが多重化された制御ファイルです。中身はまったく同じもので、Oracleは書き込みのたびに両方を更新します。

そして、この一覧はどこから来ているのか。初期化パラメータを見てみましょう。

SHOW PARAMETER control_files

出力例：

NAME                TYPE        VALUE
------------------- ----------- ------------------------------------------------
control_files       string      /opt/oracle/oradata/FREE/control01.ctl,
                                /opt/oracle/oradata/FREE/control02.ctl

同じ内容が出てきました。つまり、Oracleは初期化パラメータ control_files を見て制御ファイルの場所を知るわけです。

ここで、ちょっとした「鶏と卵」に気づきます。制御ファイルにはデータベースの構成情報が入っている。では制御ファイルの場所はどこに書いてあるのか？

答えは初期化パラメータファイル（SPFILE）です。だからSPFILEは「データベースを構成するファイル」ではなく、その 外側にある、インスタンスが読むファイル なのです。

データファイル

データファイルは、荷物が実際に入っている倉庫です。表のデータも、索引のデータも、最終的にはここに書き込まれます。

実は#1-1で出てきていた 入れ子のたとえ（記憶域の階層）を思い出してください。

表領域（Tablespace） ← 論理的な入れ物
  └ セグメント（Segment） ← 表や索引ひとつ分
      └ エクステント（Extent） ← まとめて確保される連続領域
          └ データブロック（Data Block） ← 最小単位

この論理階層のうち、表領域が物理的なデータファイルと結びつきます。1つの表領域は1つ以上のデータファイルで構成され、逆に1つのデータファイルは必ず1つの表領域に属します（1対多の関係です）。

「表領域」という論理的な入れ物に対して、「実体は結局このファイルですよ」と対応づけているのがデータファイル、と捉えてください。

代表的な表領域とその役割は次のとおりです。

表領域	役割
`SYSTEM`	データディクショナリ（DB自身の管理情報）。必須
`SYSAUX`	SYSTEMの補助。AWRなど各種機能のデータ置き場。必須
`UNDO`	変更前のデータ（ロールバックや読取り一貫性に使う）
`USERS`	ユーザーが作る表などのデフォルト置き場

実機ラボで確認

データファイルの一覧を、対応する表領域名も含めて取得します。

SELECT d.con_id, d.file#, t.name AS tablespace,
       d.name AS file_name, ROUND(d.bytes/1024/1024) AS mb
FROM   v$datafile d
JOIN   v$tablespace t ON d.ts# = t.ts# AND d.con_id = t.con_id
ORDER  BY d.con_id, d.file#;

出力例（抜粋・値は環境により異なります）：

CON_ID  FILE#  TABLESPACE  FILE_NAME                                              MB
------- ------ ----------- ------------------------------------------------ --------
      1      1  SYSTEM     /opt/oracle/oradata/FREE/system01.dbf                 xxx
      1      3  SYSAUX     /opt/oracle/oradata/FREE/sysaux01.dbf                 xxx
      1      4  UNDOTBS1   /opt/oracle/oradata/FREE/undotbs01.dbf                xxx
      1      7  USERS      /opt/oracle/oradata/FREE/users01.dbf                  xxx
      2      5  SYSTEM     /opt/oracle/oradata/FREE/pdbseed/system01.dbf         xxx
      2      6  SYSAUX     /opt/oracle/oradata/FREE/pdbseed/sysaux01.dbf         xxx
      3      9  SYSTEM     /opt/oracle/oradata/FREE/FREEPDB1/system01.dbf        xxx
      3     10  SYSAUX     /opt/oracle/oradata/FREE/FREEPDB1/sysaux01.dbf        xxx
      ...

ここで注目していただきたい点が3つあります。

1つ目：CON_ID で複数のコンテナが混ざっている

CDBルートで V$DATAFILE を見ると、CDB内の全コンテナ分のデータファイルが見えます。CON_ID=1 が CDB$ROOT（共用部）、CON_ID=2 が PDB$SEED（部屋のひな型）、CON_ID=3 以降が FREEPDB1 などのPDB（各部屋）です。PDBに直接接続して同じSQLを実行すると、そのPDBの分だけが見えます。

2つ目：SYSTEM 表領域がコンテナごとに存在する

CON_ID が違えば別の SYSTEM があります。つまり 各PDBは自分専用のデータディクショナリを持っている ということ。これがPDBの「独立性」を支える仕組みで、#1-4のマルチテナントの話につながります。

3つ目：結合条件に con_id を入れている点

CDB環境では、表領域番号 TS# は コンテナ内でしか一意ではありません。ts# だけで結合すると別コンテナの表領域と組み合わさって行が重複してしまうので、AND d.con_id = t.con_id を必ず付けます。地味ですが、CDB環境でV$ビューを結合するときの定石です。

V$DATAFILE と DBA_DATA_FILES はどう違う？

どちらもデータファイルの一覧が取れますが、情報の出どころが違います。

V$〜 で始まる動的パフォーマンス・ビューの多くは、制御ファイルやメモリ（SGA）から情報を読んでいます。制御ファイルさえ読めればよいので、MOUNT状態でも参照できます。

DBA_〜 で始まるデータディクショナリ・ビューは、SYSTEM表領域の中にある管理表を読んでいます。データファイルを開かないと読めないので、OPEN状態でないと参照できません。

障害でデータベースが開けないとき（MOUNT止まり）に「どのデータファイルがおかしいのか」を調べられるのは V$DATAFILE の側だけ、というわけです。リカバリの場面でじわじわ効いてくる違いなので、頭の片隅に置いておいてください。

なお、CDB環境では DBA_DATA_FILES は接続中のコンテナの分しか見えません。CDB全体をまとめて見たいときは CDB_DATA_FILES を使います。

オンラインREDOログ

オンラインREDOログは、作業日誌の控えです。

データベースに UPDATE を実行したとき、その変更はすぐにデータファイルへ書き込まれるわけではありません。#1-2で見たとおり、変更はまずメモリ上（データベース・バッファ・キャッシュ）で行われ、データファイルへの書き込みはDBWnがあとからまとめて行います。

では、書き込む前に電源が落ちたら？
ここでREDOログが効きます。

Oracleは 「変更をデータファイルに反映するより先に、その変更内容をREDOログに書く」 という順序を守っています（LGWRの仕事です）。日誌さえ残っていれば、あとから同じ作業をなぞり直せる。だから障害から復旧できるわけです。

REDOログには、覚えておきたい構造上の特徴が2つあります。

グループとメンバー

REDOログは「グループ」という単位で管理され、1つのグループの中に「メンバー」というファイルを複数持てます。同じグループのメンバーは、まったく同じ内容が書かれます。制御ファイルの多重化と同じ考え方で、1つ壊れても大丈夫にするための仕組みです。

グループ1 ─ メンバーA（redo01.log）  ← 内容は同じ
           └ メンバーB（redo01b.log） ← 内容は同じ
グループ2 ─ メンバーA（redo02.log）
           └ メンバーB（redo02b.log）

循環して使われる

グループ1がいっぱいになったらグループ2へ、グループ2がいっぱいになったらグループ3へ、そして最後まで行ったらグループ1に戻って上書きします。この切り替わりを ログ・スイッチ と呼びます。

日誌が無限に増えないのは便利ですが、裏返せば 古い記録は消える ということ。だから長期の復旧に備えるには、上書きされる前にコピーを取っておく必要があります。それが後述の「アーカイブREDOログ」です。

なお、データベースには最低2つのREDOログ・グループが必要です。1つしかないと、上書き中に書き込む先がなくなってしまうためです。

実機ラボで確認

グループとメンバーを結合して一覧します。

SELECT l.group#, l.status, ROUND(l.bytes/1024/1024) AS mb, f.member
FROM   v$log l JOIN v$logfile f ON l.group# = f.group#
ORDER  BY l.group#, f.member;

出力例：

GROUP#  STATUS      MB   MEMBER
------- ---------- ---- ------------------------------------------
      1  CURRENT    200  /opt/oracle/oradata/FREE/redo01.log
      2  INACTIVE   200  /opt/oracle/oradata/FREE/redo02.log
      3  INACTIVE   200  /opt/oracle/oradata/FREE/redo03.log

STATUS 列がREDOログの状態を表します。よく出てくるものを挙げると：

STATUS	意味
`CURRENT`	いま書き込み中のグループ
`ACTIVE`	書き込みは終わったが、インスタンス・リカバリにまだ必要
`INACTIVE`	リカバリに不要。上書きしてよい
`UNUSED`	まだ一度も使われていない

上の例では、グループ1が現在使用中で、2と3は待機中です。しばらく更新処理を流してから同じSQLを実行すると CURRENT が移動していきますので、余裕があれば試してみてください。ログ・スイッチを手動で起こすこともできます。

ALTER SYSTEM SWITCH LOGFILE;

実行後にもう一度先ほどのSQLを流すと、CURRENT が次のグループに移っているはずです。

この環境では各グループにメンバーが1つずつですが、本番環境では2つ以上に多重化するのが定石です。

一時ファイル

一時ファイルは、作業机です。

大きな表を ORDER BY でソートしたり、GROUP BY で集計したり、ハッシュ結合をしたり。こうした処理はまずメモリ（PGA）上で行われますが、メモリに収まりきらないときに 一時的にディスクへ退避する場所 が必要になります。それが一時表領域であり、その実体が一時ファイルです。

作業机の上に書類を広げて作業して、終わったら片付ける。机の上のものは残す必要がないし、なくなっても困らない。——この性質から、一時ファイルには他のファイルにない特徴があります。

REDOログに記録されない（変更の記録を残す必要がないため）
バックアップの対象外（失われても作り直せばよい）
V$DATAFILE には出てこない（データファイルとは別扱い。専用の V$TEMPFILE を見る）

「データベースを構成する3種類のファイル」に一時ファイルが入っていないのは、まさにこの「なくても作り直せる」性質のためです。とはいえ、実際には一時表領域がないとソート処理が動きませんので、運用上は必須の存在です。

実機ラボで確認

SELECT con_id, name, ROUND(bytes/1024/1024) AS mb FROM v$tempfile;

出力例：

CON_ID  NAME                                              MB
------- ------------------------------------------- --------
      1  /opt/oracle/oradata/FREE/temp01.dbf              xxx
      2  /opt/oracle/oradata/FREE/pdbseed/temp01.dbf      xxx
      3  /opt/oracle/oradata/FREE/FREEPDB1/temp01.dbf     xxx

データファイルのときと同じく CON_ID が付いていて、コンテナごとに一時ファイルを持てることが分かります。PDBごとに専用の一時表領域を持たせることも、CDB共通のものを使わせることもできます。

CDB/PDBでファイルはどう分かれるのか

ここまでのラボで、CON_ID が付いていたビューと、付いていなかったビューがあったことにお気づきでしょうか。実はここに、CDB構成におけるファイルの重要な切り分けが表れています。

ファイル	CDB全体で共有？コンテナごと？
制御ファイル	CDB全体で1セット（PDBは持たない）
オンラインREDOログ	CDB全体で1セット（PDBは持たない）
データファイル	コンテナごと（各PDBが自分のSYSTEM/SYSAUX等を持つ）
一時ファイル	コンテナごとに持てる
UNDO表領域	ローカルUNDO構成ではPDBごと（26aiの既定）

マンションのたとえで整理するとスッキリします。

管理台帳（制御ファイル）と工事記録（REDOログ）は、建物に1セット。管理人室にあって、住人が個別に持つものではありません。
各部屋の荷物（データファイル）は、部屋ごと。だからこそ「部屋ごと引っ越す」（PDBのプラグ／アンプラグ）ができます。

「REDOログがCDB共通」というのは初見だと少し意外かもしれません。PDBはあくまで同じインスタンス上で動く論理的な区画なので、変更の記録もCDB全体で1本にまとめられているのです。この「共有するもの／分けるもの」の設計こそがマルチテナントの肝で、次回#1-4で改めて掘り下げます。

なお、UNDOについては構成によって変わります。26aiでは ローカルUNDO（LOCAL_UNDO_ENABLED=TRUE）が既定で、PDBごとにUNDO表領域を持ちます。確認してみましょう。

SELECT property_name, property_value
FROM   database_properties
WHERE  property_name = 'LOCAL_UNDO_ENABLED';

DBの外側のファイル（SPFILE・パスワード・アーカイブ・アラートログ）

ここからは、データベースを構成するファイルではないけれど、運用には欠かせないファイルたちです。試験ではこの区別が問われますので、「3点セットの外側」として意識的に分けて覚えてください。

SPFILE / PFILE

インスタンス起動時に読まれる 初期化パラメータファイル です。SGAのサイズ、制御ファイルの場所、各種上限値などが書かれています。

PFILE（initFREE.ora）：テキスト形式。エディタで編集でき、反映には再起動が必要
SPFILE（spfileFREE.ora）：バイナリ形式。ALTER SYSTEM で動的に変更できる。現在の標準

「エンジン（インスタンス）を起動するための設定書」であって、燃料タンク（データベース）の一部ではない——という位置づけです。実際、SPFILEはインスタンスが NOMOUNT になる段階、つまり制御ファイルを読むより前に読まれます。

パスワードファイル

SYSDBA などの管理者権限で、データベースが開いていない状態でもリモートから接続できるようにするためのファイルです。$ORACLE_HOME/dbs/orapw<SID> に置かれます。

「データベースが起動していないと認証できない」のでは、そもそも起動コマンドを打てません。そのニワトリ・タマゴを解決するのが、DBの外側に置かれたこのファイルです。

アーカイブREDOログ

先ほど「オンラインREDOログは循環して上書きされる」と書きました。上書きされる前にコピーを保存しておいたものが アーカイブREDOログ です。

ARCHIVELOGモード：上書き前に自動でコピーを保存する。過去のどの時点にも戻せる
NOARCHIVELOGモード：コピーしない。古い記録は消える

本番環境では原則ARCHIVELOGモードで運用しますが、26ai Freeの既定はNOARCHIVELOG です。詳しい話はバックアップ／リカバリの章で扱いますので、今回は「モードがある」ことと「確認方法」だけ押さえます。

アラートログ／トレースファイル

データベースの起動・停止、エラー、重要な操作などが時系列で記録されるログです。トラブル時に真っ先に見るファイルで、実務での使用頻度は非常に高いものです。

これらは ADR（Automatic Diagnostic Repository） という決まったディレクトリ構造の下に出力されます。

実機ラボで確認

外側のファイルたちを、まとめて確認します。

-- 初期化パラメータファイルの場所
SHOW PARAMETER spfile

-- パスワードファイルに登録されている管理ユーザー
SELECT username, sysdba, sysoper, sysbackup FROM v$pwfile_users;

-- アーカイブ運用の状態
ARCHIVE LOG LIST

-- 診断情報（アラートログ・トレース）の出力先
SELECT name, value FROM v$diag_info;

SHOW PARAMETER spfile の出力例：

NAME     TYPE        VALUE
-------- ----------- ---------------------------------------------------
spfile   string      /opt/oracle/product/26ai/dbhomeFree/dbs/spfileFREE.ora

（パスは環境により異なります。ここに値が表示されればSPFILEで起動しており、空ならPFILEで起動しています。）

ARCHIVE LOG LIST の出力例：

データベース・ログ・モード              非アーカイブ・モード
自動アーカイブ                          使用不可
アーカイブ先                            USE_DB_RECOVERY_FILE_DEST
最も古いオンライン・ログ順序            xx
現行のログ順序                          xx

「非アーカイブ・モード（NOARCHIVELOG）」と出ました。Freeの既定どおりです。

V$DIAG_INFO の出力例：

NAME                 VALUE
-------------------- --------------------------------------------------
Diag Enabled         TRUE
ADR Base             /opt/oracle
ADR Home             /opt/oracle/diag/rdbms/free/FREE
Diag Trace           /opt/oracle/diag/rdbms/free/FREE/trace
Diag Alert           /opt/oracle/diag/rdbms/free/FREE/alert
Diag Incident        /opt/oracle/diag/rdbms/free/FREE/incident
...
Default Trace File   /opt/oracle/diag/rdbms/free/FREE/trace/FREE_ora_xxxx.trc

アラートログの実体は、Diag Trace で示されたディレクトリ配下の alert_FREE.log（テキスト形式）です。Diag Alert 配下には同じ内容がXML形式（log.xml）で出力されます。

せっかくなので、OS側から中身を覗いてみましょう。SQL*Plusを抜けて（exit）、次を実行します。

tail -30 /opt/oracle/diag/rdbms/free/FREE/trace/alert_FREE.log

先ほど ALTER SYSTEM SWITCH LOGFILE を実行した方は、その記録が残っているはずです。自分が打ったコマンドがログに現れるのを見ると、アラートログの役割が実感できると思います。

実機ラボ：自分のDBの全ファイルを一覧する

最後に、ここまで見てきたファイルを1枚のリストにまとめてみましょう。サブタイトルの回収です。

SELECT 'controlfile' AS type, name FROM v$controlfile
UNION ALL SELECT 'datafile', name FROM v$datafile
UNION ALL SELECT 'redolog',  member FROM v$logfile
UNION ALL SELECT 'tempfile', name FROM v$tempfile
ORDER BY 1, 2;

出力例（抜粋）：

TYPE         NAME
------------ --------------------------------------------------
controlfile  /opt/oracle/oradata/FREE/control01.ctl
controlfile  /opt/oracle/oradata/FREE/control02.ctl
datafile     /opt/oracle/oradata/FREE/FREEPDB1/sysaux01.dbf
datafile     /opt/oracle/oradata/FREE/FREEPDB1/system01.dbf
datafile     /opt/oracle/oradata/FREE/system01.dbf
...
redolog      /opt/oracle/oradata/FREE/redo01.log
redolog      /opt/oracle/oradata/FREE/redo02.log
redolog      /opt/oracle/oradata/FREE/redo03.log
tempfile     /opt/oracle/oradata/FREE/temp01.dbf
...

件数も数えてみます。

SELECT COUNT(*) FROM (
  SELECT name FROM v$controlfile
  UNION ALL SELECT name FROM v$datafile
  UNION ALL SELECT member FROM v$logfile
  UNION ALL SELECT name FROM v$tempfile
);

「自分のデータベースは、たったこれだけのファイルでできている」——最初にこれを実機で見ておくと、以降の章で出てくる話（バックアップは何を取るのか、リカバリで何を戻すのか）が格段に理解しやすくなります。

そして、この一覧に SPFILEもパスワードファイルもアラートログも含まれていない ことを確認してください。それらはV$ビューで「データベースのファイル」として管理されていないのです。今回いちばん伝えたかった切り分けが、そのまま出力に表れています。

まとめ

■ データベースを構成する物理ファイル

ファイル	確認するビュー	役割	たとえ
制御ファイル	`V$CONTROLFILE`	DBの構成情報。MOUNT時に読む	管理台帳・目次
データファイル	`V$DATAFILE`	実データの格納先。表領域に対応	倉庫
オンラインREDOログ	`V$LOG` / `V$LOGFILE`	変更の記録。循環使用	作業日誌の控え

■ 周辺のファイル（DBの構成要素ではないが運用に必要）

ファイル	確認方法	役割
一時ファイル	`V$TEMPFILE`	ソート等の作業領域。REDO記録なし・バックアップ不要
SPFILE / PFILE	`SHOW PARAMETER spfile`	インスタンスの初期化パラメータ
パスワードファイル	`V$PWFILE_USERS`	DB停止中でも管理者接続を可能にする
アーカイブREDOログ	`ARCHIVE LOG LIST`	REDOログのバックナンバー。26ai Freeの既定は無効
アラートログ／トレース	`V$DIAG_INFO`	稼働状況・エラーの記録。ADR配下

■ CDB/PDBでの持ち方

ファイル	持ち方
制御ファイル・REDOログ	CDB全体で1セット（PDBは持たない）
データファイル・一時ファイル	コンテナごと
UNDO表領域	ローカルUNDO構成ではPDBごと（26aiの既定）

■ 押さえておきたい3点

物理ファイルの3点セットは「制御ファイル・データファイル・オンラインREDOログ」。SPFILEやパスワードファイルは含まれない
V$〜 は制御ファイル／メモリ由来なのでMOUNTでも見える。DBA_〜 はデータディクショナリ由来なのでOPENが必要
制御ファイルとREDOログはCDB共有、データファイルはコンテナごと

次回予告

次回 #1-4 は「マルチテナント・コンテナ・データベースの利点の理解」です。

今回、データファイルが CON_ID ごとに分かれていること、各PDBが自分専用の SYSTEM 表領域を持っていることを実機で確認しました。では、なぜそんな構造になっているのか。「共有するもの／分けるもの」をこう設計したことで何が嬉しいのか。マンションのたとえを本格的に展開しながら、CDB／PDBの世界に踏み込んでいきます。

参考

Oracle AI Database 26ai ドキュメント・ライブラリ
データベースの概念（Oracle AI Database 26ai） : 物理記憶域構造、データベースを構成するファイルの概念
データベース管理者ガイド（Oracle AI Database 26ai） : 制御ファイル・REDOログ・データファイルの管理手順
データベース・リファレンス（Oracle AI Database 26ai） : V$CONTROLFILE、V$DATAFILE、V$LOG、V$DIAG_INFO 等のビュー定義
Multitenant管理者ガイド（Oracle AI Database 26ai） : CDB/PDBにおけるファイルの持ち方
バックアップおよびリカバリ・ユーザーズ・ガイド（Oracle AI Database 26ai） : ARCHIVELOGモードとアーカイブREDOログ

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up