Oracleバックグラウンドプロセス詳解：DBWn, LGWR, SMON, PMONの役割と連携

Posted at 2025-09-03

Linuxサーバーでps -ef | grep ora_コマンドを実行したことがあるなら、ora_で始まる多くのプロセスがバックグラウンドで静かに動作しているのを見たことがあるでしょう。多くの人にとって、それらは見慣れていると同時に謎めいた存在です。データベースの裏側で一体何をしているのでしょうか？そして、なぜこれらのプロセスを理解することが、Oracleの初心者とエキスパートを分ける第一歩だと言われるのでしょうか？

この記事では、ベテランDBAの視点から、Oracleの4つの主要なバックグラウンドプロセス——DBWn, LGWR, SMON, PMON——の真の役割と、それらがどのように精巧に連携し、Oracleを支えているのかを徹底的に解説します。この記事を読めば、あなたのOracleアーキテクチャに対する理解は一段と深まるはずです。

プロセスの確認

各プロセスの責務を深く掘り下げる前に、まずはシステム上でそれらを見つける方法を知る必要があります。通常、2つの方法があります。

1. オペレーティングシステムレベル

Linux/Unix環境では、簡単なpsコマンドでそれらを特定できます。

# ここでORCLはデータベースのインスタンス名(SID)です
$ ps -ef | grep ora_ | grep ORCL
oracle   12470     1  0 10:45 ?        00:00:00 ora_pmon_ORCL
oracle   12472     1  0 10:45 ?        00:00:00 ora_clmn_ORCL
oracle   12474     1  0 10:45 ?        00:00:00 ora_psp0_ORCL
oracle   12476     1  2 10:45 ?        00:00:01 ora_vktm_ORCL
...
oracle   12498     1  0 10:45 ?        00:00:00 ora_lgwr_ORCL
oracle   12500     1  0 10:45 ?        00:00:00 ora_ckpt_ORCL
oracle   12502     1  0 10:45 ?        00:00:00 ora_smon_ORCL
oracle   12506     1  0 10:45 ?        00:00:00 ora_dbw0_ORCL
...

注釈：pmon, lgwr, smon, dbw0などのプロセスがはっきりと確認できます。

2. データベース内部

データベースに接続した後、V$PROCESSビューを照会することで、より詳細な情報を取得し、バックグラウンドプロセスとOSのプロセスID（SPID）を関連付けることができます。

-- 主要なバックグラウンドプロセスの情報を照会
SELECT
    p.pname,
    p.spid,
    p.program
FROM
    v$process p
WHERE
    p.pname IN ('PMON', 'LGWR', 'DBW0', 'SMON', 'CKPT');

-- 出力例:
PNAME SPID       PROGRAM
----- ---------- ---------------------------
PMON  684393     oracle@adgcontrol (PMON)
DBW0  684449     oracle@adgcontrol (DBW0)
LGWR  684459     oracle@adgcontrol (LGWR)
CKPT  684462     oracle@adgcontrol (CKPT)
SMON  684465     oracle@adgcontrol (SMON)

これでプロセスを「捕まえた」ので、次はその中核的な責務を一つずつ分析していきましょう。

4大コアプロセスの役割分担

データベースを多忙な金融取引フロアだと想像してみてください。これら4つのプロセスは、そのフロアが効率的、安定的、かつ安全に運営されることを保証する中心的なチームです。

1. LGWR (Log Writer):

LGWRは、データの永続性（ACIDの'D'）を保証する重要な存在です。その仕事は単純に見えますが、極めて重要です。メモリ上のREDOログ・バッファを、オンラインREDOログ・ファイルに迅速かつ安全に書き込みます。

役割: トランザクションの永続性を最終的に保証する存在。REDOログ・バッファのデータをオンラインREDOログ・ファイルに書き込む責任を負う。
主な責務:
- ユーザーがコミット（COMMIT）したトランザクションによって生成されたREDOレコードをメモリからディスクに書き出す。
- ユーザーがCOMMIT成功のメッセージを受け取った時点で、そのデータ変更が永久に記録されたことを保証する。たとえその瞬間にインスタンスがクラッシュしても、データは回復可能。
トリガー:
- ユーザーがCOMMITを実行した時。
- 3秒ごと。
- REDOログ・バッファの使用量が1/3を超えた時。
- DBWnプロセスがダーティ・データ・ブロックを書き込む前（これは「ログ先行書き込み」、Write-Ahead Loggingと呼ばれる）。
設計思想:
- 高速コミット (Fast-Commit): REDOログへの書き込みはシーケンシャルI/Oであり、データファイルへのランダムI/Oよりもはるかに高速です。LGWRを先行させることで、ユーザーのCOMMIT操作はディスクへの実際のデータ書き込みを待つことなく、非常に迅速に応答を得られます。
- 回復可能性 (Recoverability): ログはデータ回復の根幹です。ログさえあれば、データファイルが破損または失われたとしても、Oracleはデータベースを障害発生前の状態に回復できます。

経験談：本番環境では、log file syncは非常に重要な待機イベントです。このイベントの平均待機時間が長すぎる場合、通常はI/Oサブシステムにボトルネックがあるか、アプリケーションのコミットが頻繁すぎることを意味します。V$SYSTEM_EVENTを照会することで、この状況を直感的に把握できます。

-- log file syncとdb file parallel writeの待機状況を確認
SELECT
    event,
    total_waits,
    time_waited_micro / 1000 AS time_waited_ms,
    -- total_waitsが0より大きい場合のみ計算し、ゼロ除算エラーを回避
    (CASE
        WHEN total_waits > 0 THEN (time_waited_micro / total_waits) / 1000
        ELSE 0
     END) AS avg_wait_ms
FROM
    v$system_event
WHERE
    event IN ('log file sync', 'db file parallel write');

-- 結果例
EVENT                    TOTAL_WAITS TIME_WAITED_MS AVG_WAIT_MS
------------------------ ----------- -------------- -----------
log file sync              154738604      103711352    .6702358
db file parallel write     170604382     85825722.4  .503068686

注釈：log file syncはユーザーがLGWRの完了を待つ総時間を示し、db file parallel writeはLGWRが実際にI/Oを実行した時間です。両者に大きな差がある場合、問題はI/O自体ではなくCPUスケジューリングにある可能性があります。

2. DBWn (Database Writer)

LGWRが「速さ」と「安定性」を追求するなら、DBWnは「効率」を追求します。メモリ（データベース・バッファ・キャッシュ）内で変更されたデータブロック（いわゆる「ダーティ・ブロック」）をディスク上のデータファイルに書き戻す役割を担います。

役割: データベース・バッファ・キャッシュの管理者。変更されたデータブロックを非同期かつ一括でデータファイルに書き込む。
主な責務:
- バッファ・キャッシュをスキャンし、ダーティ・データ・ブロックを見つける。
- これらのダーティ・ブロックをバッチ形式で対応するデータファイルに書き戻す。
トリガー:
- チェックポイント（Checkpoint）イベントが発生した時。
- ダーティ・バッファの数が特定のしきい値に達した時。
- ユーザープロセスが空きバッファを必要とし、一定数をスキャンしても見つからなかった時。
- 3秒のタイムアウト。
設計思想:
- 遅延書き込み (Lazy Writing): DBWnはデータブロックが変更されるたびに即座にディスクに書き込むわけではありません。この設計はI/O回数を大幅に削減し、多数のシングルブロック・ランダムI/Oを一度のマルチブロック・バッチI/Oに統合します。これにより、DML（INSERT, UPDATE, DELETE）操作のパフォーマンスが大幅に向上します。ユーザーの操作はメモリ内で完了すればすぐに制御を返すことができ、遅いディスク書き込みを待つ必要がありません。

実践的な観察：DBWnの書き込み性能はdb file parallel write待機イベントで測定できます。この待機イベントはDBWnプロセス専用です。このイベントの待機時間が長い場合、データファイルのI/Oにボトルネックがあることを示しています。

中核となる連携：あるCOMMITの裏話

LGWRとDBWnの役割を理解すれば、COMMIT操作の内部フローを完全に描くことができます。

ユーザーセッションがUPDATE文を実行し、メモリのバッファ・キャッシュ内のデータブロックを変更します。このブロックは「ダーティ・ブロック」になります。同時に、この変更の詳細（REDOベクター）がメモリのREDOログ・バッファに記録されます。
ユーザーがCOMMITを実行します。
ユーザーのフォアグラウンド・サーバー・プロセスがLGWRに通知します。
LGWRが起動され、このトランザクションのすべての変更記録を含むREDOエントリをREDOログ・バッファからオンラインREDOログ・ファイルに即座に書き込みます。
書き込みが成功すると、LGWRはユーザーのフォアグラウンド・プロセスに通知し、COMMIT操作が完了します。ユーザーは次の操作に進むことができます。
将来のある時点（例えばチェックポイントがトリガーされた時）に、DBWnがその「ダーティ・データ・ブロック」をバッファ・キャッシュからデータファイルに書き戻します。

よくある誤解は、COMMIT後にデータがすぐにディスクに書き込まれるというものですが、正確にはデータ変更を記述したログがすぐにディスクに書き込まれ、データ自体は後でDBWnによって書き込まれる、ということです。この「ログ先行書き込み」メカニズムは、Oracleの高性能と高信頼性の基盤です。

3. SMON (System Monitor)

SMONはデータベースの健康を守る守護神であり清掃員です。特にデータベースが異常終了した後のシステムレベルのメンテナンス作業を担当します。

役割: システムレベルの監視・クリーンアッププロセスであり、インスタンス・リカバリの中核的な実行者。
主な責務:
- インスタンス・リカバリ: データベースのSTARTUP時に、前回のシャットダウンが異常だった場合（例：SHUTDOWN ABORTやサーバーの電源喪失）、SMONは自動的にインスタンス・リカバリを実行します。REDOログ・ファイルを利用して、コミット済みだがデータファイルに未書き込みの変更をすべてロールフォワードし、未コミットのトランザクションをすべてロールバックして、データベースを一貫性のある状態に復旧させます。
- 一時セグメントのクリーンアップ: 使用されなくなった一時セグメントをクリーンアップし、領域を解放します。
- 過去のクリーンアップタスク: SMONの役割の一つに、データベースの「掃除屋」としての役割があります。典型的な例が空き領域の管理です。非常に古いディクショナリ管理表領域（DMT）の時代には、SMONは断片化した空き領域と戦うために、隣接する空きエクステントを定期的に結合する必要がありました。しかし、これはもはや過去の話です。現在のデータベースで標準となっているローカル管理表領域（LMT）は、この問題を仕組みレベルで解決しており、SMONもこの歴史的な重荷から解放されました。
設計思想: インスタンスクラッシュ後の回復プロセスを自動化し、データの一貫性を保証するとともに、定期的な領域クリーンアップタスクを担い、データベースの健全性を維持します。

4. PMON (Process Monitor)

PMONはすべてのユーザープロセスとサーバープロセスを見守り、プロセスが「予期せず死亡」した場合には、後始末をします。

役割: ユーザープロセスとサーバープロセスの監視者。プロセスが異常終了した後のリソースクリーンアップを担当する。
主な責務:
- 失敗したプロセスのクリーンアップ: ユーザーセッションが異常切断された場合（例：クライアントのクラッシュ、ネットワーク障害）、PMONが介入します。
- トランザクションのロールバック: 失敗したセッションが保持していた未コミットのトランザクションをロールバックします。
- ロックの解放: セッションが保持していたすべてのロックを解放し、他のセッションのブロッキングを防ぎます。
- リソースの解放: セッションが使用していたPGAメモリなどのリソースを回収します。
- リスナーへの登録: PMONはインスタンス情報をリスナーに登録し、クライアントがこのデータベースに接続可能であることを知らせる役割も担います。（12c以降では、この責務は主にLREGプロセスが担当します）。
設計思想: 個々のユーザープロセスの障害がデータベース全体の安定性やデータ一貫性に影響を与えないように保証し、「ゾンビプロセス」や永久にロックされたリソースの発生を防ぎます。

実践的な観察：SQLクライアントがフリーズし、OSレベルでそのプロセスをkillすると、V$SESSIONでのステータスがKILLEDに変わるのがわかります。しばらくすると、このレコードは消えます。この背後で動いているのがPMONです。プロセスが終了したことを検知し、クリーンアップ作業を開始します。

まとめ

ここまでで、Oracleの4つの主要なバックグラウンドプロセスの責務と連携について深く理解しました。

LGWR: 永続性のため、すべてのREDOを迅速に記録します。
DBWn: パフォーマンスのため、データをまとめて非同期に格納します。
SMON: 一貫性のため、障害復旧とシステムレベルのガベージコレクションを担当します。
PMON: 堅牢性のため、プロセスのベビーシッターのように、異常終了したすべてのプロセスの後始末をします。

これら4つのプロセスは、それぞれが独自の責務を持ちながら、精巧なメカニズム（ログ先行書き込みプロトコルなど）を通じて緊密に連携し、安定したOracleデータベースの基盤を形成しています。それらの動作原理を理解することは、Oracleアーキテクチャを理解する上で基本であるだけでなく、パフォーマンス診断（待機イベントの分析など）やトラブルシューティングに不可欠な知識です。

これらの四天王の他に、CKPTやARCnなど、あなたが注目した興味深いOracleバックグラウンドプロセスはありますか？それらはあなたの仕事でどのような重要な役割を果たしましたか？ぜひコメント欄で共有してください。

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