🧩 エラー概要
ORA-04031: unable to allocate n bytes of shared memory
日本語メッセージ：
ORA-04031: 共有メモリーが不足しています
このエラーは、OracleのSGA（System Global Area）やPGAなどの共有メモリ領域でメモリ割り当てに失敗したときに発生します。
特にshared poolやlarge poolなどの領域でメモリフラグメンテーション（断片化）が進行している場合によく見られます。
💡 主な発生原因
| 原因カテゴリ | 内容 |
|---|---|
| メモリ断片化 | 多数のPL/SQL・パッケージのロード／アンロードが繰り返され、shared poolが細切れになっている |
| メモリ不足 | SGA_TARGET や SHARED_POOL_SIZE の設定が小さすぎる |
| キャッシュ肥大化 | SQL文キャッシュやライブラリキャッシュに古い情報が溜まっている |
| パラメータ不整合 | 自動メモリ管理（AMM）設定が中途半端な状態になっている |
| 一時的な負荷増大 | 大量のSQL・セッションが一斉に発生したタイミング |
🔍 事前チェックポイント
| 確認項目 | SQL例 | 補足 |
|---|---|---|
| 現在のSGAサイズ | SHOW PARAMETER sga_target; | 自動メモリ管理を利用中か確認 |
| 各プールサイズ | SHOW PARAMETER shared_pool_size; | shared/large/java pool の値を把握 |
| メモリ利用状況 | SELECT * FROM v$sgastat WHERE pool='shared pool' ORDER BY bytes DESC; | メモリ断片化を確認 |
| フラグメンテーション | SELECT * FROM v$sgastat WHERE name LIKE '%free memory%'; | 空きメモリの分布を確認 |
| エラー履歴 | SHOW ALERT; または alert.log | ORA-04031発生の時刻と頻度を確認 |
🛠 対処方法まとめ
| 対処方法 | 内容 |
|---|---|
| 1. メモリサイズを増加 | ALTER SYSTEM SET shared_pool_size=800M SCOPE=SPFILE; などでサイズを拡張し、DB再起動 |
| 2. キャッシュのフラッシュ | 一時的な対応として ALTER SYSTEM FLUSH SHARED_POOL; を実行（夜間・非稼働時間帯推奨） |
| 3. 自動メモリ管理（AMM）の活用 | MEMORY_TARGET / MEMORY_MAX_TARGET を適切に設定して自動調整を有効化 |
| 4. パッケージのピン止め | DBMS_SHARED_POOL.KEEP('パッケージ名'); で頻繁に使うPL/SQLを保持し、再ロードを防止 |
| 5. 不要なSQLキャッシュ削除 | 不要なセッションや古いSQLを明示的に削除してキャッシュ整理 |
| 6. アップグレード・パッチ適用 | 特定バージョンでのバグが原因のケースもあり、最新パッチ適用を検討 |
📊 対策効果の比較
| 対応内容 | 即効性 | 永続性 | 備考 |
|---|---|---|---|
| shared poolの拡張 | ◎ | ○ | 再発抑止に効果的 |
| shared pool flush | ○ | × | 一時的（再断片化する） |
| AMM設定の見直し | ○ | ◎ | 自動調整により安定化 |
| パッケージKEEP化 | ○ | ◎ | 頻繁な再ロードを防止 |
| 不要SQL削除 | △ | △ | 効果は一時的 |
| Oracleパッチ適用 | ○ | ○ | バグ起因なら必須 |
⚙️ 設定変更例（SPFILE使用時）
再起動：
🧠 再発防止のポイント
| 観点 | 内容 |
|---|---|
| コーディング | 不要に動的SQLを多用しない（バインド変数活用） |
| 運用 | 長期間稼働するインスタンスでは定期的に再起動を検討 |
| 監視 | V$SGASTAT, AWRレポート, alert.logを定期確認 |
| 自動チューニング | ADDMやASHレポートの活用で根本分析 |
🧾 まとめ
-
ORA-04031はメモリ断片化・不足・キャッシュ肥大が主原因
-
shared pool拡張 + AMM設定で再発防止が可能
-
一時的な回避策としてFLUSH SHARED_POOLも有効だが、根本解決には設定見直しが必須
安定稼働を目指すなら、AWRレポートによる定期分析とパッケージKEEP化を組み合わせるのがベストです。
