【Oracle】ORA-04030の原因と解決方法｜PGA不足・プロセスメモリ不足を切り分ける

ORA-04030: out of process memory は、Oracleのサーバープロセスやバックグラウンドプロセスが、処理に必要な私有メモリを確保できなかったときに発生するエラーです。共有プール不足を示す ORA-04031 と似ていますが、ORA-04030で主に見るべき場所は、PGA、OSメモリ、プロセスごとのメモリ上限、大量処理SQLやPL/SQLのメモリ使用量です。

対処は単純にメモリ設定を増やすだけではありません。どのプロセスが、どの種類のメモリを、どの処理で使い切ったのかを確認しないと、再発時に同じSQLやバッチがまた失敗します。この記事では、障害時に見る順番、確認SQL、よくある原因、設定変更前の注意点を実務寄りに整理します。

ORA-04030とは

Oracle公式のエラー説明では、ORA-04030はプロセス私有メモリを確保できない、またはOSメモリやプロセス単位の上限に達した場合に発生するとされています。また、1つのOracleプロセスには内部的な上限があり、単一プロセスで極端に大きなメモリを使う場合はメモリリーク疑いも含めて調査対象になります。メッセージには、確保しようとしたバイト数と、どの領域で失敗したかを示す引数が出ることがあります。

代表的なメッセージは次のような形です。

ORA-04030: out of process memory when trying to allocate 16328 bytes (koh-kghu sessi,pl/sql vc2)

koh-kghu sessi や pl/sql vc2 のような引数は、どの内部領域でメモリ確保に失敗したかを調べる手掛かりです。ただし、引数だけで断定せず、発生時刻、SQL、セッション、PGA使用量、OSメモリを合わせて確認します。Oracleのメモリ全体像は SGA・PGAメモリ管理完全ガイド も参考になります。

まず見る場所

原因別の当たり付け

ORA-04030は原因が広いため、最初に症状から当たりを付けると調査が早くなります。同じメモリ不足でも、DB全体のPGA不足、特定SQLの暴走、PL/SQLの実装問題、OS側の制限では対処が変わります。

ORA-04031との違い

ORA-04030とORA-04031はどちらもメモリ不足系ですが、見る場所が違います。ORA-04031は共有プールなどSGA側の共有メモリ不足が中心です。一方、ORA-04030はサーバープロセスなどが持つ私有メモリ、つまりPGAやOSプロセスのメモリ上限側を疑います。

共有プール側の切り分けが必要な場合は ORA-04031: 共有メモリを割り当てられません 完全ガイド を参照してください。

PGAの状態を確認する

まず、PGA全体の使用状況を確認します。pga_aggregate_target や pga_aggregate_limit に近づいていないか、自動PGA管理がどの程度メモリを使っているかを見ます。

SHOW PARAMETER pga_aggregate_target;
SHOW PARAMETER pga_aggregate_limit;

SELECT name,
       value,
       isdefault,
       issys_modifiable
FROM v$parameter
WHERE name IN ('pga_aggregate_target', 'pga_aggregate_limit')
ORDER BY name;

SELECT name,
       value,
       unit
FROM v$pgastat
WHERE name IN (
  'aggregate PGA target parameter',
  'aggregate PGA auto target',
  'total PGA allocated',
  'total PGA inuse',
  'maximum PGA allocated',
  'over allocation count'
)
ORDER BY name;

over allocation count が増えている場合、PGAターゲットを超えてメモリ割り当てが必要になった履歴があります。ただし、これだけで設定不足とは断定できません。どのセッションやSQLがメモリを使っているかまで追います。

メモリを使っているプロセスを探す

次に、プロセス単位のメモリ使用量を見ます。ORA-04030は「DB全体が少しずつ足りない」よりも、特定プロセスが大きくなって失敗しているケースが多いです。

SELECT p.pid,
       p.spid,
       s.sid,
       s.serial#,
       s.username,
       s.program,
       s.sql_id,
       pm.category,
       ROUND(pm.allocated / 1024 / 1024, 1) AS allocated_mb,
       ROUND(pm.used / 1024 / 1024, 1) AS used_mb,
       ROUND(pm.max_allocated / 1024 / 1024, 1) AS max_allocated_mb
FROM v$process p
JOIN v$session s
  ON s.paddr = p.addr
JOIN v$process_memory pm
  ON pm.pid = p.pid
WHERE s.username IS NOT NULL
ORDER BY pm.allocated DESC;

SELECT s.sid,
       s.serial#,
       s.username,
       s.program,
       s.sql_id,
       ROUND(p.pga_used_mem / 1024 / 1024, 1) AS pga_used_mb,
       ROUND(p.pga_alloc_mem / 1024 / 1024, 1) AS pga_alloc_mb,
       ROUND(p.pga_max_mem / 1024 / 1024, 1) AS pga_max_mb
FROM v$session s
JOIN v$process p
  ON p.addr = s.paddr
WHERE s.username IS NOT NULL
ORDER BY p.pga_alloc_mem DESC
FETCH FIRST 30 ROWS ONLY;

古いバージョンで FETCH FIRST が使えない場合は、外側で ROWNUM を使って上位件数に絞ってください。対象セッションを強制切断する場合は影響範囲を確認します。手順は セッションの確認・強制切断方法完全ガイド にまとめています。

発生中のSQLを確認する

メモリを多く使っているセッションの SQL_ID が分かったら、SQL本文と実行計画を確認します。大きなソート、ハッシュ結合、集計、並列実行、巨大な中間結果があると、PGAを大きく使うことがあります。

SELECT sql_id,
       child_number,
       executions,
       rows_processed,
       elapsed_time,
       sql_text
FROM v$sql
WHERE sql_id = '&SQL_ID';

SELECT *
FROM table(dbms_xplan.display_cursor('&SQL_ID', NULL, 'ALLSTATS LAST +PEEKED_BINDS'));

実行計画で HASH JOIN、SORT、GROUP BY、WINDOW SORT、PX 系の処理が大きい場合、SQL改善や並列度の見直しでメモリ使用量を下げられることがあります。

PL/SQLの大量処理で起きるケース

PL/SQLでは、無制限の BULK COLLECT、大きすぎるコレクション、巨大な文字列配列、カーソルを閉じない処理がORA-04030の原因になることがあります。特に「全件を一度に配列へ載せる」実装は危険です。

DECLARE
  TYPE t_rows IS TABLE OF big_table%ROWTYPE;
  l_rows t_rows;
BEGIN
  SELECT *
  BULK COLLECT INTO l_rows
  FROM big_table;

  -- 全件をメモリに載せるため、件数次第でPGAを圧迫する
END;
/

DECLARE
  CURSOR c IS
    SELECT * FROM big_table;

  TYPE t_rows IS TABLE OF big_table%ROWTYPE;
  l_rows t_rows;
BEGIN
  OPEN c;
  LOOP
    FETCH c BULK COLLECT INTO l_rows LIMIT 1000;
    EXIT WHEN l_rows.COUNT = 0;

    -- ここで分割処理する
    l_rows.DELETE;
  END LOOP;
  CLOSE c;
END;
/

BULK処理は高速化に有効ですが、LIMITなしで大量データを持つとPGAを圧迫します。実装パターンは PL/SQL バルク処理完全ガイド、カーソル処理の考え方は PL/SQL カーソル完全ガイド も参考になります。

OS側のメモリとプロセス上限を確認する

DB内のPGAだけでなく、OS側の制限も見ます。Linuxでは物理メモリ、スワップ、プロセス上限、ulimit、HugePages、cgroupやコンテナ制限が関係することがあります。Windowsでは仮想メモリやサービスアカウントの制限、同居アプリのメモリ使用量も確認します。

free -m
vmstat 1 5
ulimit -a
ps -eo pid,ppid,user,rss,vsz,comm --sort=-rss | head -30

pga_aggregate_limitを増やす前に確認すること

pga_aggregate_limit や pga_aggregate_target を増やすと改善するケースはあります。ただし、原因がSQLの巨大な中間結果やPL/SQLの無制限配列なら、設定を増やしても再発を先送りするだけです。

-- 例: 変更する場合は、OSメモリと他インスタンスの使用量を確認してから実施する
ALTER SYSTEM SET pga_aggregate_target = 4G SCOPE=BOTH;
ALTER SYSTEM SET pga_aggregate_limit  = 8G SCOPE=BOTH;

一時対応と恒久対応

切り分けの流れ

1. アラートログとトレースで発生時刻、プロセスID、SQL ID、エラー引数を確認する
2. v$pgastat でPGA全体の逼迫を確認する
3. v$process、v$session、v$process_memory で大きいプロセスを探す
4. SQL IDから実行計画を確認し、ソート、ハッシュ結合、並列実行、巨大な中間結果を探す
5. PL/SQLならBULK COLLECT、配列、カーソル、文字列連結の実装を確認する
6. OSメモリ、スワップ、ulimit、同居プロセス、複数インスタンスの合計メモリを確認する
7. 設定変更、SQL修正、処理分割、サーバー増強のどれが適切かを決める

関連エラーとの見分け方

よくある質問

ORA-04030はPGAを増やせば直りますか？

直る場合はありますが、最初から増やす判断は危険です。特定SQLやPL/SQLが異常にメモリを使っている場合、PGAを増やしても再発を遅らせるだけになります。v$process_memory、v$pgastat、SQL実行計画を確認してから判断します。

ORA-04030とORA-04031はどちらがPGA不足ですか？

主にPGAやプロセス私有メモリを疑うのはORA-04030です。ORA-04031は共有プールなどSGA側の共有メモリ不足を疑います。エラー番号だけで設定を変えず、発生箇所とメモリ種別を分けて確認します。

本番障害時に最初に何を残すべきですか？

発生時刻、アラートログ、トレースファイル、OSメモリ状況、対象セッション、SQL ID、PGA使用量を残します。セッションを切断して復旧する場合も、先にSQL IDとプロセス情報を控えておくと、恒久対応につなげやすくなります。

まとめ

ORA-04030は、Oracleプロセスが必要な私有メモリを確保できないときに発生します。PGAを増やせば直る場合もありますが、実務では特定SQL、PL/SQLの大量配列、並列実行、OSメモリ不足、プロセス上限が原因になっていることも多いです。

まずアラートログとトレースで発生箇所を押さえ、v$pgastat、v$process_memory、v$process、v$session で対象を絞ります。そのうえで、SQL改善、BULK処理の分割、PGA設定、OSメモリ、同時実行数を順番に見直すのが安全です。

参考

• Oracle Database Error Help: ORA-04030
• Oracle Autonomous Health Framework: Resolving ORA-04030