過去バージョン

この記事の要点

SMON (System Monitor): Oracle の必須バックグラウンドプロセス。落ちると DB がクラッシュ 主な役割 4 つ: ① インスタンス起動時のクラッシュリカバリ ② 空き領域 (Free Extent) の結合 ③ 一時セグメントのクリーンアップ ④ 分散トランザクションの解消 PMON との違い: SMON = システム全体の監視、PMON = 個別ユーザプロセスの監視 確認: SELECT * FROM v$bgprocess WHERE name = "SMON" SMON が止まると: ORA-00474、ORA-00475 などが出てインスタンスが死ぬ → アラートログ確認 → SR 起票

SMON とは

SMON (System Monitor) は Oracle Database の必須バックグラウンドプロセスの 1 つ。インスタンス起動と同時に立ち上がり、停止と同時に終了します。SMON が異常終了すると Oracle インスタンス全体がクラッシュします。

同じく必須プロセスの PMON (Process Monitor)、DBWn (Database Writer)、LGWR (Log Writer)、CKPT (Checkpoint)、ARCn (Archiver) などと共に、Oracle インスタンスの根幹を成します。

SMON の 4 つの主要な役割

① インスタンス起動時のクラッシュリカバリ

Oracle が停電やクラッシュで異常停止した後、次回起動時に SMON がREDO ログを再適用して整合性を回復します:

[シナリオ]
1. インスタンス稼働中に停電
2. 未コミットトランザクション複数あり
3. 電源復旧後 STARTUP

[SMON の動作]
1. REDO ログから前回チェックポイント以降の変更を再適用 (Roll Forward)
2. 起動完了後、UNDO セグメントから未コミット分を巻き戻し (Roll Back)
3. インスタンス整合性確保

これにより ACID の D (Durability) が保証される

② Free Extent の結合 (Coalesce of Free Extents)

古い Dictionary-Managed Tablespace (DMT) では、削除した領域の断片化を SMON が定期的に統合していました。現代の Locally-Managed Tablespace (LMT) ではビットマップ管理なのでこの役割は無くなっています。

③ 一時セグメント (Temporary Segment) のクリーンアップ

失敗したトランザクションが作った一時セグメント、CREATE INDEX 中に異常終了したセッションが残した中間データなどを定期的に掃除します:

-- 一時セグメントの状況確認
SELECT tablespace_name, segment_type, COUNT(*)
FROM dba_segments
WHERE segment_type LIKE 'TEMPORARY%'
GROUP BY tablespace_name, segment_type;

-- DBA_UNDO_EXTENTS で残骸確認
SELECT * FROM dba_undo_extents
WHERE status = 'EXPIRED' AND ROWNUM <= 10;

④ 分散トランザクション (In-Doubt) の解消

2 フェーズコミット中にネットワーク障害などで宙ぶらりんになった分散トランザクションを、SMON が定期的にチェックして自動解消します:

-- In-doubt 分散トランザクションの一覧
SELECT local_tran_id, global_tran_id, state, mixed
FROM dba_2pc_pending;

-- 手動解決 (DBA が判断)
COMMIT FORCE 'tran_id';
ROLLBACK FORCE 'tran_id';

SMON の状態確認

-- 全バックグラウンドプロセスの状態
SELECT name, description, paddr
FROM v$bgprocess
WHERE paddr != '00';

-- SMON 単体で確認
SELECT * FROM v$bgprocess WHERE name = 'SMON';

-- SMON のセッション情報
SELECT s.sid, s.serial#, s.program, p.spid, s.status, s.wait_class
FROM v$session s, v$process p
WHERE s.paddr = p.addr
  AND s.program LIKE '%(SMON)%';

-- OS プロセスとして確認 (Linux)
-- $ ps -ef | grep ora_smon
-- oracle 1234 1 0 09:00 ? 00:00:01 ora_smon_ORCL

SMON と PMON の違い

項目	SMON (System Monitor)	PMON (Process Monitor)
監視対象	インスタンス全体・データファイル	各ユーザプロセス・サーバプロセス
主な仕事	クラッシュリカバリ / 領域管理 / 一時セグメント整理	異常終了プロセスのクリーンアップ / ロールバック / ロック解放 / リスナー登録
動作タイミング	起動時 + 定期 (約 5 分間隔)	常時 + プロセス監視
停止時の影響	インスタンス停止	インスタンス停止
OS プロセス名	ora_smon_SID	ora_pmon_SID

SMON 起因の典型的なトラブル

症状	原因	対処
ORA-00474: SMON プロセスが異常終了	内部エラー / メモリ不足 / バグ	アラートログ + トレース → SR 起票
ORA-00475: TRWR プロセスが SMON より先に終了	システムエラー	同上、再起動
クラッシュリカバリが終わらず STARTUP が遅い	REDO ログが大量 / I/O 遅延	v$instance_recovery で進捗確認
UNDO テーブルスペース満杯	SMON のクリーンアップが追いつかない	UNDO_RETENTION / TS サイズ見直し
一時表領域が膨らみ続ける	分散トランザクションの残骸	dba_2pc_pending 確認

SMON 関連の隠しパラメータ (※通常変更しない)

-- (Oracle Support の指示があった場合のみ)
ALTER SYSTEM SET "_smu_debug_mode" = 4;
ALTER SYSTEM SET "_smon_internal_errlimit" = 50;

-- SMON の起動頻度 (定数)
-- デフォルト 約 300 秒 (5 分)
-- アイドル時は 1500 秒 (25 分) まで延長

DBA としての日々の運用

1. アラートログを毎日確認 — SMON エラーがあれば即対応
2. v$instance_recovery でリカバリ時間予測を把握
3. UNDO テーブルスペースの空きを監視 (Cloud Control 等)
4. 分散トランザクションが残らないか dba_2pc_pending をチェック
5. 定期パッチを当てる — SMON 起因のバグは Critical Patch Update で修正される

SMON の場所 (アラートログ)

# 標準的な場所
$ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/alert_$ORACLE_SID.log

# SMON のトレースファイル
$ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/${ORACLE_SID}_smon_*.trc

# adrci で確認
$ adrci
adrci> show alert -tail 100
adrci> show incident
adrci> show problem

FAQ

Q: SMON を kill したらどうなる？
A: Oracle インスタンス全体が即終了します (ORA-00474)。やってはいけません。本番では絶対禁止。

Q: SMON が CPU を 100% 消費している
A: クラッシュリカバリ中か、巨大な UNDO 領域の整理中。一時的なら正常。長引くなら ASH/AWR で待機イベント解析、My Oracle Support に問い合わせ。

Q: RAC 環境では？
A: 各インスタンスに SMON が存在し、Instance Recovery では生存インスタンスの SMON が死んだインスタンスをリカバリします (Cluster Recovery)。