ORACLE Master Silver 無料サンプル

Oracle の基本アーキテクチャでは、インスタンスとデータベースは明確に別の概念である。

• インスタンス＝メモリ構造（SGA）とバックグラウンドプロセス群の組み合わせ。STARTUP のたびに新しく確保・起動され、SHUTDOWN で消える一時的な実体である。
• データベース＝ディスク上に永続する物理ファイル群（データファイル・制御ファイル・REDOログファイル等）の集合。インスタンスを介さなくても、ファイルとして存在し続ける。

非 RAC（単一インスタンス）構成では、通常1つのインスタンスが1つのデータベースをマウント・オープンする 1:1 の関係になる。 一方 Oracle RAC（Real Application Clusters）構成では、複数のインスタンスが1つの共有データベースに同時アクセスする 1:N の関係が成立する。

この「インスタンス＝メモリ＋プロセス（揮発性）」「データベース＝ディスク上のファイル（永続）」という区別は、Oracle アーキテクチャ全体の理解の出発点となる。

SGA（System Global Area）は、インスタンスの起動時に確保される共有メモリ領域で、 そのインスタンスに接続するすべてのサーバープロセス・バックグラウンドプロセスから共有される。主な構成要素は次のとおり。

• データベースバッファキャッシュ：ディスクから読み込んだデータブロックをメモリ上にキャッシュする領域。
• REDOログバッファ：コミット前後の変更内容（REDOエントリ）を一時的に保持するリングバッファ。LGWR がここから REDOログファイルへ書き出す。
• 共有プール（Shared Pool）：解析済み SQL・PL/SQL のライブラリキャッシュや、データディクショナリキャッシュを保持する。
• ラージプール／Java プール／ストリームプール（設定時）：RMAN バックアップ、共有サーバー、Java 実行、並列問合せ等で使う補助領域。

一方、PGA（Program Global Area）はサーバープロセスごとに個別に割り当てられる非共有メモリであり、 ソート領域・カーソル状態・セッション変数等を保持する。SGA には含まれない点が本問の核心。

共有プール（Shared Pool）は主に2つのキャッシュから構成される。

• ライブラリキャッシュ（Library Cache）：解析済みの SQL 文・PL/SQL プログラム単位（プロシージャ・パッケージ等）とその実行計画をキャッシュする。同一テキストの SQL 文が再実行されると、ハッシュ値で一致を検出し、構文解析・実行計画生成を省略（ソフトパース）できる。
• データディクショナリキャッシュ（行キャッシュ）：表・列・索引・権限などのメタデータ（データディクショナリの行）をキャッシュし、解析時にディクショナリ表への物理アクセスを減らす。

本問のように「完全一致の SQL 文の再実行でパースコストが下がる」現象は、ライブラリキャッシュに解析済みカーソル（共有カーソル）がヒットしたことによる。 なお SQL 文のテキストが1文字でも異なる（バインド変数化されていないリテラルの違い等）とハードパースになりやすい点も併せて押さえる。

データベースバッファキャッシュは、ディスクから読み込んだデータブロックのコピーを保持する SGA の領域である。 ブロックには ピンされている／使用されていない（unused） といった状態のほか、変更を受けたブロックはダーティ（dirty）としてマークされる。

UPDATE によってメモリ上のブロックが変更されると、そのブロックはダーティブロックになる。 変更内容はまず REDOログバッファに記録され、COMMIT 時に LGWR が REDOログファイルへ書き込むが、 データブロック自体（バッファキャッシュ内のダーティブロック）をディスクのデータファイルへ書き戻すのは DBWn の仕事であり、COMMIT のタイミングとは非同期である。

つまり、COMMIT 直後でも、そのダーティブロックはまだバッファキャッシュに残ったまま（ディスクへの書き戻し未完了）であることが多い。 これが Oracle の「高速コミット（fast commit）」の仕組み＝コミット時に保証されるのは REDOログの永続化であって、データファイルへの即時反映ではないという重要な性質である。

REDOログバッファは SGA 内の小さなリングバッファで、変更（REDOエントリ）を一時的に保持する。 このバッファの内容を REDOログファイルへ書き出すのが LGWR（Log Writer）バックグラウンドプロセスであり、次のいずれかの条件で書き出しをトリガーする。

• COMMIT の発行：トランザクションが COMMIT されると、LGWR は該当セッションの REDO を同期的にディスクへ書き込む（コミットが完了したと応答を返す前に書き込みを保証する＝耐久性の担保）。
• REDOログバッファが 1/3 満杯になったとき：バッファがあふれる前に定期的にフラッシュする。
• REDOログバッファに約1MBのREDOが蓄積されたとき：容量ベースのしきい値。
• 3秒ごと（タイムアウト）：上記の条件に達していなくても、一定間隔で書き出す。
• DBWn がダーティバッファをディスクへ書き出す前：Write-Ahead Logging の原則により、対応する REDO が先にディスクへ書かれていることを保証するため、DBWn は書き出し前に LGWR に先行書き込みを要求する。

一方、単純な SELECT（読み取り専用の問合せ）は REDOを生成しないため、LGWR の書き出しトリガーにはならない。

PGA（Program Global Area）は、サーバープロセス（またはバックグラウンドプロセス）1つにつき1つ確保される非共有メモリ領域である。 主に次のようなセッション固有・プロセス固有の情報を保持する。

• ソート領域（sort area）：ORDER BY・GROUP BY・ハッシュ結合等で使う作業領域。
• セッション情報・カーソル状態：オープン中のカーソルの実行状態など。
• スタック領域：セッションのローカル変数など。

SGA がすべてのプロセスから共有されるのに対し、PGA はそのプロセス自身だけがアクセスできる点が本質的な違いである。 専用サーバー（dedicated server）構成では、クライアント接続ごとに専用サーバープロセスが起動し、それぞれが自分専用の PGA を持つ。

サイズは自動 PGA 管理（PGA_AGGREGATE_TARGET）によってインスタンス全体で動的に調整されるのが一般的である。

DBWn（Database Writer, DBW0 等）は、データベースバッファキャッシュ内のダーティブロック（変更済みで未反映のブロック）を データファイルへ書き出すバックグラウンドプロセスである。書き出しは主に次の契機で発生する。

• チェックポイント（checkpoint）の発生時：CKPT がチェックポイントを起動すると、DBWn は該当するダーティバッファをディスクへ書き出す。
• ダーティバッファ数が閾値を超えたとき：空きバッファが不足してくると、サーバープロセスが新しいブロックをキャッシュに読み込む前に DBWn へ書き出しを要求する。
• 3秒ごとのタイムアウト：定期的にも書き出しを行う。
• 表領域の OFFLINE化・読み取り専用化、正常な SHUTDOWN 等：該当ファイルの整合性を確保するために書き出す。

重要な点として、DBWn の書き出しは COMMIT のタイミングとは同期しない。COMMIT 時に同期的に書き込みが保証されるのは REDOログ（LGWR の仕事）であり、 DBWn によるデータブロックのディスク反映は遅延して（非同期に）行われるのが Oracle の設計の要点である（バッファキャッシュの効果を最大化するため）。

Oracle は障害からの回復可能性（リカバラビリティ）を保証するため、Write-Ahead Logging（先行書き込みログの原則）を採用している。

具体的には、あるデータブロックへの変更に対応する REDOエントリが REDOログファイルへ書き込まれる前に、そのデータブロック自体（ダーティバッファ）をディスクへ書き出してはならないという順序が保証される。

• DBWn がダーティバッファを書き出そうとするとき、対応する REDO がまだディスクに書かれていなければ、DBWn は LGWR に先に REDO を書き込ませてから自分の書き出しを行う。
• これにより、仮に書き出し中にクラッシュが発生しても、ディスク上には「変更後のデータブロック」より先に「その変更を再現できる REDO」が必ず存在する状態が保たれ、整合性のあるリカバリが可能になる。

もし逆順（データブロックが先、REDOが後）で書き込まれると、書き出し直後にクラッシュした場合、その変更を再現する REDO が無いままデータブロックだけが変更された状態でディスクに残り、リカバリで矛盾が生じ得る。

CKPT（Checkpoint Process）は、チェックポイントの発生時に制御ファイルとデータファイルヘッダーを更新するバックグラウンドプロセスである。

• チェックポイントとは、「SGA 内のダーティバッファをデータファイルへ書き出す」処理と、その結果を制御ファイル・各データファイルヘッダーへ記録する処理を伴うイベントである。
• 実際にダーティバッファをディスクへ書き出すのは DBWnの仕事であり、CKPT 自身はデータブロックの書き出しは行わない。CKPT の役割は、チェックポイントが完了したという事実（チェックポイント SCN 等）を制御ファイルとデータファイルヘッダーに記録・シグナルすることに限定される。
• この記録により、インスタンスリカバリ時に「どの SCN 以降の REDO を適用すればよいか」を判断できる（チェックポイント以前の変更はすでにデータファイルへ反映済みとみなせる）。

SMON（System Monitor Process）は、インスタンス全体のメンテナンスを担うバックグラウンドプロセスで、主な役割は次のとおり。

• インスタンスリカバリ（instance recovery）：異常終了（SHUTDOWN ABORT・インスタンスクラッシュ等）の後、次回起動（STARTUP）時に SMON が REDOログを適用してロールフォワード（前進リカバリ）を行い、続いて未コミットのトランザクションをロールバックする。
• 一時セグメントの領域解放：不要になった一時セグメントの領域を回収する。
• 空きエクステントの結合（coalesce）：辞書管理表領域（dictionary-managed tablespace）における隣接する空きエクステントを結合し、断片化を解消する。

一方、ユーザープロセスの強制切断・セッションのクリーンアップ（デッドロック検出後の異常セッションの後始末等）は主に PMON（Process Monitor）の役割であり、SMON の主要機能ではない。

Oracle インスタンスには、STARTUP 時に必ず起動される必須（mandatory）バックグラウンドプロセスがある。代表的なものは次の5つである。

• PMON（Process Monitor）：プロセス障害の後始末。
• SMON（System Monitor）：インスタンスリカバリ・領域メンテナンス。
• DBWn（Database Writer）：ダーティバッファのディスク書き出し。
• LGWR（Log Writer）：REDOログバッファの書き出し。
• CKPT（Checkpoint Process）：チェックポイント情報の記録。

これに対し、ARCn（Archiver Process）はデータベースが ARCHIVELOG モードのときにのみ起動されるオプションのプロセスであり、 NOARCHIVELOG モードのインスタンスでは起動されない。つまり ARCn は「常に必須」のプロセスではなく、アーカイブREDOログモードに依存する条件付きプロセスである。

データベースバッファキャッシュ内のブロックは、大まかにLRU（Least Recently Used）アルゴリズムに基づくリストで管理される。

• ブロックが読み込まれ・アクセスされるとMRU 端（最近使用された側）に置かれ、しばらくアクセスされないブロックは徐々にLRU 端（最も使用されていない側）へ移動していく。
• 新しいブロックをキャッシュへ読み込む必要が生じると、サーバープロセスはLRU 端に近い、変更されていない（クリーンな）ブロックを優先して置き換え候補にする。
• ダーティブロック（変更済みで未反映）はそのままでは置き換えの対象にならず、置き換える前にDBWn によってディスクへ書き出されてから初めて解放・再利用される。
• 大きな全表スキャン（フルテーブルスキャン）で読み込まれたブロックは、通常のブロックとは異なる扱い（LRU リストの末端寄りに置かれる等）を受け、他の頻繁にアクセスされるブロックを不必要に追い出さないよう配慮される。

Oracle データベース（ディスク上に永続する実体）は、主に次の物理ファイル群から構成される。

• データファイル：表・索引などのデータを格納する。
• 制御ファイル（control file）：データベースの物理構造（ファイル名・場所）、データベース名、タイムスタンプ、チェックポイント情報等のメタデータを保持する小さなバイナリファイル。STARTUP 時に必ず必要。
• REDOログファイル（オンラインREDOログファイル）：REDOログバッファからLGWRによって書き出される、変更履歴（REDOエントリ）を記録する循環利用のファイル群。

これらに対し、SGA（共有プール・バッファキャッシュ等）はメモリ構造であり、インスタンスの一部としてメモリ上にのみ存在する。SHUTDOWN すると解放され、ディスク上のファイルとしては存在しない。

共有プールのライブラリキャッシュは、SQL文のテキストが完全一致する場合にのみ解析結果（共有カーソル）を再利用できる（ソフトパース）。 リテラル値がそのまま埋め込まれた SQL（バインド変数を使わない SQL）は、値が変わるたびに別の SQL 文として扱われ、新規にハードパースされる。

この結果：

• 大量のユニークな SQL 文が次々とライブラリキャッシュに登録され、共有プールの空き容量を圧迫する。
• 空き容量が不足すると、Oracle は使用頻度の低いキャッシュ済みオブジェクト（他の解析済みカーソル等）をエイジアウト（追い出し）し、次回それらが必要になったときに再度ハードパースが発生する。
• これは典型的な「バインド変数の未使用によるライブラリキャッシュのスラッシング」であり、CPU 負荷増大とラッチ競合（library cache latch 等）を招く。

対策としては、アプリケーション側でバインド変数を使用する、または CURSOR_SHARING 初期化パラメータ（FORCE 等）でリテラルを自動的にバインド変数化する方法がある。

インスタンスリカバリ（STARTUP 時に SMON が自動的に実行）は、2段階で構成される。

• ① ロールフォワード（前進リカバリ）：最後にディスクへ反映されていた時点（最終チェックポイント）以降の REDOログ（オンラインREDOログファイル）を適用し、クラッシュ直前のコミット済み・未コミットを問わずすべての変更をデータファイルへ再現する。これにより、クラッシュ時点でメモリ上にしかなかった変更（ダーティバッファの内容）を復元する。
• ② ロールバック（後退リカバリ）：ロールフォワードによって復元されたデータの中には、クラッシュ時点でまだコミットされていなかったトランザクションの変更も含まれる。これらは UNDO 情報を使ってロールバックし、コミット済みの一貫した状態に戻す。

この一連の処理は SMON が自動的に行い、通常は DBA が明示的に何かを実行する必要はない（メディアリカバリ＝データファイル喪失時のリストア＆リカバリとは別物）。

専用サーバー（dedicated server）構成では、クライアントが接続するとそのクライアント専用のサーバープロセスが1つ起動される。

• サーバープロセス（server process）は、クライアントが発行した SQL 文の解析・実行・データの取得を行い、必要であればデータベースバッファキャッシュにデータブロックを読み込み、結果をクライアントへ返す。サーバープロセスは自分専用の PGA を持つ。
• これに対し、バックグラウンドプロセス（DBWn, LGWR, CKPT, SMON, PMON 等）は、インスタンス全体の維持・保守を行うインスタンス起動時に立ち上がる別種のプロセス群であり、個々のクライアントの SQL 実行そのもの（解析・実行）は行わない。

つまり「クライアントの SQL を直接処理するのはサーバープロセス」「インスタンス全体の維持（書き出し・リカバリ等）を行うのがバックグラウンドプロセス」という役割の分離が Oracle プロセスアーキテクチャの基本である。

Oracle の SGA コンポーネント（共有プール・バッファキャッシュ・ラージプール等）のサイズ管理には複数のモードがある。

• 手動共有メモリ管理：SHARED_POOL_SIZE・DB_CACHE_SIZE 等の個別パラメータを DBA が明示的に指定する方式。この場合、各コンポーネントのサイズは指定された値に固定され、Oracle が自動的にコンポーネント間でメモリを融通することはない。
• 自動共有メモリ管理（ASMM）：SGA_TARGET を設定すると、共有プール・バッファキャッシュ等のサイズを Oracle がワークロードに応じて自動的に再配分する。
• 自動メモリ管理（AMM）：MEMORY_TARGET を設定すると、SGA と PGA の間でもメモリが自動的に配分される（さらに大きな粒度の自動化）。

本問のように個別パラメータを明示指定している構成では、共有プールが不足してもバッファキャッシュの余剰メモリを自動的に融通することはない。DBA が各パラメータを手動で調整する必要がある。

両者は名前が似ているが、それぞれメモリ構造と物理ファイルという別の層に属する。

• REDOログバッファ：SGA 内のメモリ領域で、変更（REDOエントリ）が発生するたびに一時的にそこへ書き込まれる小さなリングバッファ。サイズは LOG_BUFFER 初期化パラメータで制御され、通常は数MB程度と小さい。
• オンラインREDOログファイル：ディスク上の物理ファイルで、LGWR が REDOログバッファの内容を書き出す先。複数のログファイルをグループとして循環利用（ログスイッチ）する。

流れとしては：変更発生 → REDOログバッファ（メモリ）に記録 → LGWR がオンラインREDOログファイル（ディスク）へ書き出し、という順序になる。 REDOログバッファは揮発性（インスタンス障害で失われる）だが、書き出し済みのオンラインREDOログファイルはディスク上に永続し、リカバリの拠り所となる。

MOUNT段階では、初期化パラメータ CONTROL_FILES に指定された制御ファイルをオープンし、 その中に記録されているデータファイルとREDOログファイルの所在・名前・状態を読み取る。 ただし、この段階ではデータファイル自体はまだオープンされていない。

MOUNT状態は主に、データファイルのリネーム・追加、REDOログの構成変更、アーカイブモードの切り替え （ALTER DATABASE ARCHIVELOG/NOARCHIVELOG）、リカバリ実行前の準備など、 データベース全体に影響する構造変更をデータファイルをオープンする前に行いたい場面で使われる。

SQL>STARTUP MOUNT
ORACLE instance started.
Database mounted.
（この状態でSELECT * FROM V$DATAFILE;は成功するが、一般ユーザーの表への問い合わせはORA-01219等で失敗する）

STARTUP（引数省略時）は NOMOUNT → MOUNT → OPEN の3段階を連続実行する。 OPEN段階では、制御ファイルに記録されたすべてのオンラインデータファイルとREDOログファイルがオープンされ、 必要であればインスタンス・リカバリ（クラッシュリカバリ）が自動実行され、一般ユーザーの接続・SQL実行が可能になる。

一方、読み取り専用（read-only）表領域の作成やオフライン化はDBAが任意に行うSQL操作であり、 OPENという「段階」自体が自動的にすべての表領域を読み取り専用へ変更するわけではない。 表領域のオンライン/オフライン状態は制御ファイルに記録された既存の状態がそのまま引き継がれるだけである。

SQL>STARTUP
ORACLE instance started.
Database mounted.
Database opened.
（Database opened. の表示後、一般ユーザーの接続とSELECT/DML実行が可能になる）

SHUTDOWN には4モードあり、待つ対象が段階的に厳しくなる。

• NORMAL（デフォルト）：新規接続を禁止し、全接続ユーザーが自発的に切断するまで待つ。最も時間がかかりうる。
• TRANSACTIONAL：新規接続を禁止し、実行中のトランザクションが完了するのを待ってから切断・停止する（タイムアウトは無く、COMMIT または ROLLBACK されるまで待ち続ける）。
• IMMEDIATE：現在のSQL文の完了は待たず（コミットされていないトランザクションはロールバック）、即座にユーザーを切断してシャットダウンする。ただし停止前にクリーンなチェックポイント処理は行われる。
• ABORT：チェックポイントもロールバックも行わず、インスタンスを強制終了する。次回起動時にクラッシュリカバリが必要になる。

NORMAL/TRANSACTIONAL/IMMEDIATEはいずれもクリーンシャットダウン（次回起動時にインスタンスリカバリ不要）である点が共通する。

SQL>SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
（正常終了のログ。ABORTの場合はこのようなクリーンな終了メッセージ列にならず即座に停止する）

SHUTDOWN ABORT はチェックポイントやロールバックを行わずインスタンスを即座に停止するため、 コミット済みだがまだデータファイルへ書き込まれていない変更（REDOログにのみ記録された変更）や、 未コミットのトランザクションがデータファイル上に不整合として残った状態になる。

この状態でも通常の STARTUP は問題なく実行できる。OPEN段階でOracleは自動的に インスタンス・リカバリ（クラッシュリカバリ）を行い、①オンラインREDOログを使って、コミット済み・未コミットを問わずクラッシュ直前までのすべての変更をロールフォワード（前進適用）し、 ②その後、未コミットだった変更をロールバック（UNDOを使って取り消し）することで、データベースを一貫した状態に自動的に戻す。 特別なRMANやDBA操作を追加で行う必要はない。

SQL>STARTUP
ORACLE instance started.
Database mounted.
Database opened.
（内部でロールフォワード→ロールバックが自動実行され、メッセージ上は通常起動と同様にDatabase opened.まで到達する）

STARTUP FORCE は、実質的に 「稼働中インスタンスがあれば SHUTDOWN ABORT で強制停止し、続けて STARTUP を実行する」のと等価なコマンドである。

通常のSTARTUPは、インスタンスが既に起動中（NOMOUNT/MOUNT/OPENいずれかの状態）だとエラーになり実行できない。 しかし障害対応時などで「インスタンスがどの状態で止まっているか分からない・SHUTDOWNが通常モードで応答しない」といった状況では、 STARTUP FORCE 一発で「強制停止→起動」をまとめて行える。DBAが状況の切り分けに手間取らずに済む実務上便利なショートカットである。

SQL>STARTUP FORCE
（内部でSHUTDOWN ABORT相当の停止 → STARTUP相当の起動が連続実行され、最終的にDatabase opened.まで到達する）

STARTUP でファイルを明示指定しない場合、Oracleはデフォルトの場所（$ORACLE_HOME/dbs など）で 次の優先順位でファイルを探索する。

• ① spfile${ORACLE_SID}.ora（サーバーパラメータファイル・バイナリ形式）
• ② spfile.ora
• ③ init${ORACLE_SID}.ora（テキスト形式PFILE）

両方存在する場合は①のSPFILEが優先され、PFILEは読まれない。 SPFILEは ALTER SYSTEM で動的に変更・永続化できる点がPFILE（テキストエディタで手動編集するのみ）との大きな違いであり、 この優先順位ゆえに現在のOracle運用ではSPFILEの使用がデフォルト・推奨とされる。

SQL>STARTUP
（$ORACLE_HOME/dbs/spfile${ORACLE_SID}.ora が存在すればそれが読み込まれ、init${ORACLE_SID}.oraは無視される）

ALTER SYSTEM SET parameter = value SCOPE = { MEMORY | SPFILE | BOTH } の各値の意味は次の通り。

• SCOPE=MEMORY：実行中インスタンスのメモリ上のみに反映。SPFILEには書き込まれないため、次回再起動すると元の値に戻る。
• SCOPE=SPFILE：SPFILEにのみ書き込む。実行中インスタンスには反映されない＝次回起動時から有効になる。静的パラメータ（起動時にしか変更できないパラメータ）を変更する際はこちらを使う。
• SCOPE=BOTH：現在のインスタンスとSPFILEの両方に反映（動的パラメータのみ指定可）。PFILEで起動している場合はSPFILEが無いためこの指定はエラーになる。

SCOPE省略時、SPFILEで起動していればデフォルトは BOTH として扱われる。

SQL>ALTER SYSTEM SET open_cursors=500 SCOPE=MEMORY;
System altered.
（インスタンス再起動後にopen_cursorsを確認すると、SPFILE未反映のため元の値に戻っている）

初期化パラメータは V$PARAMETER ビューの ISSYS_MODIFIABLE 列で分類できる。

• 動的パラメータ：ISSYS_MODIFIABLE = IMMEDIATE または DEFERRED。稼働中のインスタンスに対して ALTER SYSTEM でその場（または新規セッションから）反映できる。
• 静的パラメータ：ISSYS_MODIFIABLE = FALSE。ALTER SYSTEM SET ... SCOPE=SPFILE（または直接PFILEを編集）でファイルに書き込むことはできるが、その変更が実際に効くのは次回インスタンス再起動後で、稼働中のインスタンスの動作には一切影響しない。

代表例として CONTROL_FILES（制御ファイルの場所）は静的パラメータであり、実行中に制御ファイルの場所を差し替えることはできない。

SQL>SELECT name, isses_modifiable, issys_modifiable FROM v$parameter WHERE name='control_files';
NAME           ISSES_MODIFIABLE  ISSYS_MODIFIABLE
control_files  FALSE             FALSE
（ISSYS_MODIFIABLE=FALSEが静的パラメータであることを示す）

CREATE SPFILE FROM PFILE は、指定したテキスト形式の PFILEの内容を読み取り、それに基づいてバイナリ形式のSPFILEを新規作成するコマンドである。 逆方向（SPFILEからPFILEを生成）も CREATE PFILE FROM SPFILE で行える。

典型的な利用場面は、①これまでPFILEのみで運用していたインスタンスをSPFILE運用へ移行したい時、 ②SPFILEが破損・誤設定されて起動できなくなった際に、事前にバックアップしておいたPFILE（テキストなので直接編集・復旧しやすい）から 正常なSPFILEを作り直す時、の2つ。

このコマンド自体は現在稼働中のインスタンスのパラメータをその場で変更するものではない。あくまでファイルを生成するだけであり、 次回のSTARTUPからそのSPFILEが使われる。

SQL>CREATE SPFILE FROM PFILE='/u01/app/oracle/product/19/dbs/initorcl.ora';
File created.
（$ORACLE_HOME/dbs/spfileorcl.ora が新規作成される。稼働中インスタンスのパラメータ値はこの時点では変化しない）

アラートログ（alert_${ORACLE_SID}.log、19c以降はXML形式のログも同時出力される）は、 データベース・インスタンス全体に関わる重大なイベントを時系列で記録する中心的なログファイルである。

記録される代表的な内容：

• STARTUP／SHUTDOWNの実行と、その際に使用された初期化パラメータの一覧（デフォルト値以外）
• ログスイッチ（REDOログの切り替え）の発生
• 表領域・データファイルの作成／追加／リサイズなどの構造変更
• ORA-00600（内部エラー）やORA-07445などの重大エラー、ブロック破損の検出
• チェックポイント関連の情報や、リカバリ処理の実施状況

アラートログは1インスタンスにつき1つで、DBAが障害調査・稼働状況確認の際に最初に確認する基本のログである。 個々のセッションのSQL文やSQL実行結果までは記録しない（それは監査証跡やSQLトレースの領域）。

alert_orcl.log の抜粋例：
Starting ORACLE instance (normal)
...
ARCH: STARTING ARCH PROCESSES
Thread 1 opened at log sequence 152
  Current log# 2 seq# 152 mem# 0: /u01/.../redo02.log
...
（SQL文そのものは記録されず、インスタンス起動・ログスイッチ等のイベントのみが記録される）

ADRは、初期化パラメータ DIAGNOSTIC_DEST を起点にしたディレクトリ階層で診断情報を一元管理する仕組みである。 基本構造は次の通り。

• $DIAGNOSTIC_DEST/diag/rdbms/<db_unique_name>/<instance_name>/ を1つのADRホームとする
• その下に trace/（アラートログ・バックグラウンド/サーバープロセスのトレースファイル）、incident/（重大障害＝インシデントごとの診断データ一式）、alert/（XML形式アラートログ）、cdump/ などのサブディレクトリが自動的に作られる

ADRの導入以前は初期化パラメータ BACKGROUND_DUMP_DEST／USER_DUMP_DEST でトレース出力先をそれぞれ個別指定していたが、 11g以降はこれらがDIAGNOSTIC_DESTに統合され、DBAが診断ファイルを探し回らずに済むよう一元化されている。 ADRの操作には adrci（ADRコマンドラインインタフェース）を使う。

adrci>show homes
ADR Homes:
diag/rdbms/orcl/orcl
（DIAGNOSTIC_DEST配下に diag/rdbms/<db_unique_name>/<instance>/ の階層でtrace・incident・alert等が格納されている）

トレースファイルは大きく2種類に分けられる。

• バックグラウンドプロセスのトレース：PMON・SMON・DBWn・LGWR などのバックグラウンドプロセスが、 自身が検知した問題や処理内容を記録する。異常終了時に多くの情報を残す。
• サーバープロセスのトレース：ユーザーセッションに対応するサーバープロセスが、 SQL_TRACE（または DBMS_MONITOR／DBMS_SESSION.SET_SQL_TRACE）を有効にした際に、 そのセッションが実行したSQL文の解析・実行・フェッチの統計情報を記録する。パフォーマンス調査（tkprofでの整形が定番）に使う。

いずれもADRの trace/ ディレクトリに、${ORACLE_SID}_${プロセス種別}_${プロセスID}.trc のような命名規則で出力される。

$ADR_HOME/trace/ の例：
orcl_pmon_12345.trc      （バックグラウンドプロセスPMONのトレース）
orcl_ora_23456.trc       （SQL_TRACE有効化中のサーバープロセスのトレース。tkprof orcl_ora_23456.trc output.txt で整形可能）