Oracleメモリー構造の基本とパフォーマンスを最大化するチューニング戦略

Oracle Master Gold

2025.04.132026.05.24

Oracleデータベースのパフォーマンスを最適化する上で、「メモリーコンポーネントの適切な設計と管理」は最も費用対効果の高いチューニング要素の1つです。

「SGAとPGAの違いや役割が曖昧」「バッファキャッシュや共有プールをどのサイズに設定すべきか分からない」「自動メモリー管理のベストプラクティスを知りたい」といった疑問を持つシステム管理者や開発者に向けて、Oracleのメモリー構造の全体像、各コンポーネントが処理速度に与える影響、そして現場で使える確認用SQLと具体的なチューニングアプローチを解説します。

Statspackとは？SEでも使えるOracle性能診断ツールの基本と活用法

Oracleのパフォーマンス分析というと「AWR（Automatic Workload Repository）」が思い浮かぶかもしれませんが、AWRはEnterprise Edition（EE）限定で、Diagnostic Packのライセ…

AWR（Automatic Workload Repository）とは？Oracle性能分析の基礎から実践まで解説！

Oracle Databaseの運用中、「システムのレスポンスが急に遅くなった」「CPU使用率が高止まりしている」といったパフォーマンス問題に直面したことはありませんか？そんな時に最も頼りになる公式ツールが AWR（Automatic Wo…

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？

Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？

結論：メモリー不足時の症状と即効性のある対策
Oracleメモリー構成の2大コンポーネント
1. メモリー構成の全体図と基本特性
SGA（System Global Area）の内訳と役割
1. 主要コンポーネントの詳細とパフォーマンスへの影響
PGA（Program Global Area）の構成と役割
1. PGAがボトルネックになりやすい代表的な処理
メモリー管理方式：AMMとASMMの違い
1. 管理方式の比較
実践：メモリー関連の確認用SQL
トラブルシューティング（代表的なORAエラーと対処法）
運用・監視・セキュリティ上の注意点
エディションによる機能差の整理
FAQ：よくある質問
まとめ：メモリーチューニングの5大原則

結論：メモリー不足時の症状と即効性のある対策

データベースの処理遅延がメモリー起因である場合、症状に応じて以下のコンポーネントを特定・調整することで、レスポンスを大幅に改善できます。

物理I/O（ディスク読み込み）が多発して遅い
- 原因: Buffer Cache（データベース・バッファ・キャッシュ）が不足し、メモリ上に対象データが保持できていない。
- 対策: SGA_TARGET または DB_CACHE_SIZE を拡張してヒット率を上げる。
同じSQL文のはずなのに実行するたびに解析処理が走り、CPU負荷が高い
- 原因: Shared Pool（共有プール）が不足し、解析済みの実行計画がすぐにキャッシュから追い出されている（ハードパースの多発）。
- 対策: SHARED_POOL_SIZE を拡張するとともに、SQLをバインド変数化して実行計画の再利用を促す。
大量データのソートや結合処理（HASH JOIN）の際、TEMP表領域への書き込みが発生して極端に遅くなる
- 原因: PGA（プログラム・グローバル領域）のサイズが不足し、ワークエリアが不足している。
- 対策: PGA_AGGREGATE_TARGET を拡張し、メモリ内（In-Memory）での処理を完結させる。

Oracleメモリー構成の2大コンポーネント

Oracleインスタンスのメモリー領域は、その共有範囲と用途に応じてSGAとPGAという2つの主要なアーキテクチャに分類されます。

メモリー構成の全体図と基本特性

+--------------------------------------------------------------+
|                      Oracleインスタンスメモリー                 |
+-------------------------------+------------------------------+
|      SGA (System Global Area)  |   PGA (Program Global Area)  |
|      【共有メモリー領域】      |     【専用メモリー領域】     |
+-------------------------------+------------------------------+
| ・全ユーザーセッションで共有   | ・各サーバープロセスごとに独立|
| ・インスタンス起動時に一括確保 | ・セッション接続時に動的に確保|
| ・データキャッシュや解析用領域 | ・ソートや結合などの作業用領域|
+-------------------------------+------------------------------+

名称	用途	主な特徴
SGA（System Global Area）	データベース全体のデータや制御情報をキャッシュする。	すべての接続セッション・プロセスから共通で参照される領域。
PGA（Program Global Area）	個別のユーザー要求（SQL）を処理する作業スペース。	他のセッションからはアクセスできない独立した排他的な領域。

SGA（System Global Area）の内訳と役割

SGAは、ディスクI/Oの削減やSQL解析プロセスの高速化を担う複数の個別コンポーネント（プール）で構成されています。

【SGAの内部構造】
+-------------------------------------------------------------------------+
| SGA                                                                     |
|  +-------------------------------------------------------------------+  |
|  | 1. データベース・バッファ・キャッシュ (Buffer Cache)              |  |
|  |    - ディスクから読み込んだデータブロックを一時保持（I/O削減）    |  |
|  +-------------------------------------------------------------------+  |
|  | 2. 共有プール (Shared Pool)                                        |  |
|  |    - ライブラリ・キャッシュ（SQL/実行計画）、データ辞書キャッシュ     |  |
|  +-------------------------------------------------------------------+  |
|  | 3. REDOログ・バッファ (Redo Log Buffer)                           |  |
|  |    - データの変更履歴（REDOデータ）をディスク（LGWR）に書く前のバッファ |  |
|  +-------------------------------------------------------------------+  |
|  | 4. ラージ・プール / Javaプール / インメモリ領域（※環境に応じた任意構成）|  |
|  +-------------------------------------------------------------------+  |
+-------------------------------------------------------------------------+

主要コンポーネントの詳細とパフォーマンスへの影響

1. データベース・バッファ・キャッシュ（Buffer Cache）

役割: ディスク（データファイル）から読み取ったデータブロックのコピーを保持します。
チューニングへの影響: この領域が適正サイズより小さいと、必要なデータがキャッシュから頻繁に追い出され、低速な物理ディスクI/Oが頻発します（キャッシュ・ヒット率の低下）。

2. 共有プール（Shared Pool）

役割: 実行されたSQL文、PL/SQLコード、およびオプティマイザが生成した「実行計画」をキャッシュするライブラリ・キャッシュや、表・列の定義情報を保持するデータ辞書キャッシュを含みます。
チューニングへの影響: 領域が不足すると、過去に解析したSQLの実行計画が消失し、SQL実行のたびにCPU負荷の高い構文解析・最適化処理（ハードパース）が強制され、ラッチ競合などの原因になります。

3. REDOログ・バッファ（Redo Log Buffer）

役割: データの挿入・更新・削除に際して生成される変更履歴（REDOエントリー）を、オンラインREDOログファイルへ書き出す前に一時的に格納する循環バッファです。
チューニングへの影響: 大量更新（バッチ処理など）の際、バッファが小さすぎるとログ書き込みプロセス（LGWR）の完了を待つ待機イベント（log buffer space など）が発生し、システム全体の書き込み性能がボトルネックとなります。

4. その他のオプションプール

ラージ・プール（Large Pool）: RMAN（バックアップ/リカバリ処理）、共有サーバー接続、または並列クエリの作業用に大きなメモリーブロックを割り当てるための独立領域。
Javaプール（Java Pool）: データベース内でJavaストアドプロシージャなどを実行する際に使用。
インメモリ領域（In-Memory Area）: 分析クエリを高速化するため、データをカラム型（列指向）形式で保持する高速な拡張メモリー領域（※有償の Oracle Database In-Memory オプションが必要）。

PGA（Program Global Area）の構成と役割

PGAは、ユーザーからの要求を個別に処理するサーバープロセスが、並替えやデータ結合のために排他的に使用するプライベートな作業用メモリー空間です。

【PGAのワークエリア構成】
+---------------------------------------------------+
| PGA (プロセス単位で個別に割当て)                  |
|  +---------------------------------------------+  |
|  | ソート・エリア (ORDER BY, GROUP BYの処理)   |  |
|  +---------------------------------------------+  |
|  | ハッシュ・エリア (HASH JOINのハッシュ表作成) |  |
|  +---------------------------------------------+  |
|  | セッション・メモリー (カーソル状態、変数情報) |  |
|  +---------------------------------------------+  |
+---------------------------------------------------+

PGAがボトルネックになりやすい代表的な処理

ORDER BY や GROUP BY による大規模なソート操作
大規模テーブル同士の結合（HASH JOIN）
ウィンドウ関数（ROW_NUMBER() などの分析関数）の多用

PGA内のワークエリア（ソート・エリアやハッシュ・エリア）が処理対象のデータ量に対して不足している場合、Oracleは処理中のデータを一時的にディスク上のTEMP表領域（一時表領域）に書き出して処理を継続します。メモリ内処理（ワンパス/最適な実行）に比べてディスクへのI/O負荷が数百倍に膨れ上がるため、バッチ処理や集計処理が著しく遅延する原因になります。

メモリー管理方式：AMMとASMMの違い

Oracleデータベースには、これら複数のメモリーコンポーネントを自動で最適化するための管理方式が用意されています。ワークロードの変化に応じて各プールのサイズが動的に変更されるため、管理の手間を大幅に削減できます。

管理方式の比較

管理方式	概要と対象パラメータ	メリット	デメリット・注意点	推奨される環境
AMM (Automatic Memory Management)	SGAとPGAの総和を1つの枠としてOracleが自動統合管理する。・`MEMORY_TARGET` ・`MEMORY_MAX_TARGET`	データベース全体のメモリー配分が完全に自動化され、最も運用の手間が省ける。	Linux環境において、巨大なページファイルを扱う HugePages 機能と同時に使用できない。	Windows環境、または物理メモリサイズが比較的小規模なシステム。
ASMM (Automatic Shared Memory Management)	SGAの総枠のみを自動管理し、PGAはそれとは別に全体の目標総量を設定して個別に管理する。・`SGA_TARGET` ・`PGA_AGGREGATE_TARGET`	物理I/O用（SGA）と個別ワークエリア用（PGA）のバランスを維持しつつ、 HugePages を活用できる。	SGAとPGAの枠をまたいだメモリーの融通は行われない。	Linux環境におけるエンタープライズシステムのデファクトスタンダード（推奨）。

Linux環境におけるベストプラクティス

Linux OS上で稼働する大規模なOracleデータベースでは、パフォーマンスを担保するために HugePages の設定が不可欠です。そのため、AMMではなく**ASMM（SGAとPGAを分けて設定する方式）**を採用するのが設計上の定石です。

実践：メモリー関連の確認用SQL

現在割り当てられている各メモリーコンポーネントのステータスやサイズを、システム辞書ビューからリアルタイムで確認するためのSQLスクリプトです。

実行に必要な権限と環境

以下の動的パフォーマンス・ビュー（V$ビュー）へのアクセスには、SYSDBA 権限、または SELECT ANY DICTIONARY 権限が必要です。マルチテナント（CDB/PDB）構成の場合は、対象となるプラガブル・データベース（PDB）にセッションを切り替えてから実行してください。

1. SGA全体の概略値を確認する

SHOW SGA;

SQLの意図と結果:

SQL*Plusやサポートされるクライアント環境において、固定サイズ、可変サイズ、データベース・バッファ、REDOバッファの4つのセグメントに分類されたSGAの全体容量（バイト数）を簡易的に一覧表示します。

2. 動的なSGAコンポーネントの現行サイズを確認する

SELECT component, current_size / 1024 / 1024 AS size_mb
FROM v$sga_dynamic_components;

SQLの意図と結果:

自動メモリー管理（ASMM等）によって現在割り当てられている shared pool や DEFAULT buffer cache などの最新サイズ（MB単位）を一覧取得し、どのコンポーネントがメモリーを多く消費しているかを把握します。

3. PGAの利用統計および最大消費量を確認する

SELECT name, value
FROM v$pgastat
WHERE name IN ('aggregate PGA target parameter', 'current PGA allocated', 'maximum PGA allocated');

SQLの意図と結果:

パラメータで指定されたPGA全体の目標値（target）に対して、現在インスタンス全体で実際に割り当てられているPGA総量（current）と、起動以降に記録した最大消費量（maximum）を比較し、PGA不足の予兆がないかを検証します。

トラブルシューティング（代表的なORAエラーと対処法）

メモリー関連の設定不備や急激な負荷増加によって発生する典型的なエラーコードと、安全な対処手順です。

エラーコード	主な原因	確認方法	参照系・安全な対処手順
ORA-04031 unable to allocate bytes of shared memory	共有プール（Shared Pool）の空き容量が不足し、新しいSQLの解析用メモリーが確保できない。	`V$SHARED_POOL_RESERVED` ビューで要求の失敗回数（`request_failures`）を確認する。	一時的な対応として `ALTER SYSTEM FLUSH SHARED_POOL;` を実行してフラグメンテーションを解消するか、根本対策として `SHARED_POOL_SIZE` を拡張する。
ORA-04030 out of process memory when trying to allocate bytes	OSレベル、またはOracleのプロセス上限に達し、PGA用のプライベート物理メモリが確保できない。	アラートログを確認し、特定のプロセス（サーバープロセス）が制限に達していないか捕捉する。	クエリの見直しによるソート処理の削減、またはOS側の接続ユーザーに対するリソース制限（`ulimit -v` 等）および `PGA_AGGREGATE_LIMIT` パラメータの見直しを行う。

運用・監視・セキュリティ上の注意点

過剰な割り当てによるOSメモリ枯渇のリスク:データベースを高速化したいからといって、サーバーに搭載されている物理メモリーの限界近くまでSGAやPGAのターゲット（SGA_TARGET + PGA_AGGREGATE_TARGET）を過剰に大きく設定してはいけません。OS自体や他のプロセスが使用する領域が圧迫されると、OSレベルでのスワップ（Swap）が発生します。スワップが発生すると、メモリー内容がディスクに退避されるため、データベース全体のパフォーマンスが通常時の数十分の一以下にまで急激に劣化します。全体のメモリー割り当ては、OSおよび他プロセスの取り分（最低でも物理メモリの20%〜30%程度）を必ず残すように設計してください。
オンライン変更後の原状回復:ASMMが有効な環境において ALTER SYSTEM SET sga_target = XXXM; などのコマンドを用いて動的にサイズを変更した場合、予期せぬパフォーマンス変動（プラン変更や他プールの圧迫）が起きた際は、即座に変更前の数値へ再度 ALTER SYSTEM コマンドで戻すことが可能です。ただし、変更後のサイズに合わせて縮小された他のコンポーネントが自動で元のサイズに再拡張されるまでには、内部的なタイマーによる時差が発生する場合がある点に留意してください。

エディションによる機能差の整理

Oracle Databaseの主要なメモリー制御機能（SGA/PGAの個別構成要素、ASMM、AMMなどの自動管理機能）は、Enterprise Edition（EE）とStandard Edition 2（SE2）のどちらのエディションでも差別化されることなく、共通でフル機能が利用可能です。

メモリー関連機能・オプション	Enterprise Edition	Standard Edition 2
SGA/PGA 各種基本コンポーネント	〇（すべて利用可能）	〇（すべて利用可能）
自動メモリー管理（AMM / ASMM）	〇（すべて利用可能）	〇（すべて利用可能）
Oracle Database In-Memory	〇（別途有償オプションライセンスが必要）	×（機能自体が使用不可）

FAQ：よくある質問

Q1. バッファキャッシュのサイズは大きければ大きいほど良いのでしょうか？

A1. 基本的にはキャッシュ容量が大きいほど物理I/Oが減り高速化しますが、限界値（必要なデータがすべて載るサイズ）を超えるとそれ以上の効果は得られません。また、上述の通りOSの物理メモリー上限を超えて設定するとスワップを誘発し、システム全体が停止・遅延する致命的なリスクに繋がります。

Q2. ASMMを利用している場合、個々の DB_CACHE_SIZE や SHARED_POOL_SIZE は指定しなくてよいですか？

A2. はい、基本的には 0 に設定（未指定）しておくことで、Oracleがワークロードに応じて全自動で最適化します。ただし、特定のコンポーネントがこれ以上小さくなってほしくないという「最低保証値（下限値）」を設けたい場合は、個別のパラメータに最小サイズを明示的に指定することも可能です。

Q3. PGAの最大消費量を制限するパラメータはありますか？

A3. はい、Oracle Database 12c以降では PGA_AGGREGATE_LIMIT という初期化パラメータが導入されています。これにより、インスタンス全体のPGA消費量が指定した上限に達した場合、最もPGAを浪費しているセッションの呼び出しを自動的に中断させ、OSのメモリー枯渇やシステムダウンを未然に防ぐことができます。