Advisory / Memory セクションは、メモリのサイジングが適切かどうかを評価するセクション群です。「もっとメモリを増やすべきか」「現在の設定で無駄がないか」を Oracle 自身が試算した結果が確認できます。
1. Memory Dynamic Components— メモリ動的コンポーネント
何を表すか: SGA 内の各コンポーネント（Buffer Cache / Shared Pool / Java Pool 等）の Begin/End サイズと、スナップ期間中の Resize 操作回数・タイプ。
- 読み方: Op Count > 0 のコンポーネントはスナップ期間中に動的Resizeが発生した。GROW（増加）/ SHRINK（縮小）と Mode（DEF:遅延 / IMM:即時）を確認。
- 閾値・注意点: SGA_TARGET が設定されている環境では SGA 全体サイズは変わらないが、内部コンポーネントは ASMM により動的に調整される。Resize が頻繁に発生する場合はメモリ競合の兆候。
- 関連セクション: Memory Resize Operations / Buffer Pool Advisory
- 使うシーン: SGA内メモリ動的調整の確認
項目の意味と着目点 — Memory Dynamic Components
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Cache | コンポーネント名（D:buffer cache / shared pool / java pool 等） | D: プレフィックスは Default バッファプール |
| Begin Size (M) | スナップ開始時点のサイズ（MB） | SGA_TARGET 設定値と比較して割当比率を確認 |
| End Size (M) | スナップ終了時点のサイズ（MB） | Begin との差がリサイズ量 |
| Op Count | スナップ期間中のリサイズ操作回数 | 0 なら変化なし。大きい場合は頻繁に再調整が行われている |
| Last Op Type | 最後のリサイズ種別（GROW / SHRINK / STATIC） | SHRINK が繰り返されるコンポーネントは需要に対して過剰 |
| Last Op Mode | リサイズの即時性（IMM:即時 / DEF:遅延） | IMM は即時メモリ移動。DEF は Oracle が安全なタイミングで実施 |
2. Memory Resize Operations— メモリResize操作履歴
何を表すか: スナップ期間中に発生した具体的なメモリResize操作の一覧（開始時刻・経過時間・前後サイズ・完了状態）。
- 読み方: Status=COM（Complete）なら正常完了。ERR は Resize 失敗（ORA-04031 等が同時に発生していないか確認）。Elap(s) が大きいと Resize 処理自体に時間がかかっている。
- 閾値・注意点: DEF モード（Deferred）は即時反映されないため、DB Time への影響は小さい。IMM モードは即時反映で一時的な待機が増える可能性がある。
- 関連セクション: Memory Dynamic Components
- 使うシーン: メモリ調整の詳細タイムライン確認
項目の意味と着目点 — Memory Resize Operations
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Start Time | Resize 操作の開始時刻 | Wait Events の時刻と照合して Resize が性能影響を与えたか確認 |
| Elap(s) | Resize 処理に要した時間（秒） | 大きい場合は大量メモリ移動が発生。IMM モードでは一時的な待機増加の可能性 |
| Cache | リサイズ対象のコンポーネント名 | — |
| Init Size (M) | Resize 前のサイズ（MB） | — |
| Delta (M) | 変化量（MB）。正=増加、負=縮小 | 縮小後に ORA-04031 が発生していないか Wait Events を確認 |
| Final Size (M) | Resize 後のサイズ（MB） | — |
| Status | COM（完了）/ ERR（失敗） | ERR の場合はメモリ不足またはラッチ競合が原因 |
3. Buffer Pool Advisory— バッファプールアドバイザ
何を表すか: Buffer Cache を現在サイズの 10%〜200% に変化させた場合の推定物理読込数・推定Read時間・%DB time を試算した表。
- 読み方: 現在サイズ（Size Factr = 1.0）の行が基準。サイズを増やしてもEstd Phys Readsが減らなくなる「膝点（knee point）」が最適サイズの目安。
- 閾値・注意点: 膝点を超えて倍増させても改善が 10〜15% 程度にとどまる場合はコスト対効果が低い。膝点が現在サイズより小さい場合は縮小の余地があることを示す。
- 関連セクション: Buffer Pool Statistics / Cache Sizes
- 使うシーン: Buffer Cache のサイジング判断
項目の意味と着目点 — Buffer Pool Advisory
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Size (M) | 仮想的な Buffer Cache サイズ（MB） | Size Factr = 1.0 の行が現在設定値 |
| Size Factr | 現在サイズに対する倍率 | 1.0 が現在値の基準。0.5 / 1.5 / 2.0 等で比較 |
| Buffers (K) | そのサイズに対応するバッファ数（千単位） | — |
| Phys Read Factr | 現在に対する推定物理読込の倍率 | 1.0 が現在値。1.0 未満なら増設で読込減少、1.0 超なら縮小で悪化 |
| Estd Phys Reads (K) | 推定物理読込数（千単位） | 膝点：サイズ増加に対して減少量が急激に鈍る点が最適サイズの目安 |
| Estd %dbtime | 推定 DB Time に占める Buffer Cache 読込の割合 | 現在値より大幅に改善しない場合は増設効果が小さい |
4. Buffer Pool Statistics— バッファプール統計
何を表すか: バッファプール（Default/Keep/Recycle）ごとの Buffers 数・Hit%・Gets・Physical Reads/Writes・Buffer Busy Waits。
- 読み方: Hit% ≥ 90% が目安。Gets 数と Physical Reads の比で実際のヒット率を確認。Buffer Busy Waits > 0 ならどのクラスで発生したか Buffer Wait Statistics で特定。
- 閾値・注意点: Free Buffer Waits = 0 は良好（DBWR が十分速い）。Write Complete Waits = 0 も正常。Buffer Busy Waits が多い場合はホットブロックまたは競合の多いオブジェクトが存在する。
- 関連セクション: Buffer Wait Statistics / Buffer Pool Advisory
- 使うシーン: バッファキャッシュ効率の確認
項目の意味と着目点 — Buffer Pool Statistics
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Pool | バッファプール種別（D:Default / K:Keep / R:Recycle） | Keep プールがある場合は頻繁アクセス表が明示的にキャッシュされている |
| Buffers | バッファ数（ブロック単位） | Buffer Cache サイズ / db_block_size で算出可能 |
| Hit% | バッファキャッシュヒット率（%） | 90% 以上が目安。低い場合は Buffer Pool Advisory でサイズ増設を検討 |
| Gets | 論理読込（バッファアクセス）回数 | Instance Activity の session logical reads と照合 |
| Physical Reads | キャッシュミスによる物理読込数 | Gets × (1 - Hit%/100) と概ね一致 |
| Physical Writes | DBWR によるダーティバッファの書込数 | Tablespace IO Writes と照合 |
| Free Buffer Waits | 空きバッファ待機回数 | 0 以外は DBWR の書込が追いついていない |
| Buffer Busy Waits | バッファ競合待機回数 | 0 以外は Buffer Wait Statistics でクラス別内訳を確認 |
| Write Complete Waits | バッファ書込完了待機回数 | 0 以外は DBWR がバッファを使用中に競合が発生 |
5. Buffer Wait Statistics— バッファ待機統計
何を表すか: Buffer Busy Waits がどのバッファクラス（segment header / data block / undo header 等）で発生しているかの内訳。
- 読み方: segment header での待機は PCTFREE / FREELIST の設定問題が多い。data block での待機は特定ブロックへの競合（ホットブロック）の可能性。undo header は UNDO 設定問題。
- 閾値・注意点: Total Wait Time が 0 秒であれば件数が多くても実害は少ない。件数が多い場合は Segments by Buffer Busy Waits で対象オブジェクトを特定。
- 関連セクション: Segments by Buffer Busy Waits / Buffer Pool Statistics
- 使うシーン: バッファ競合の種類特定
項目の意味と着目点 — Buffer Wait Statistics
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Class | バッファクラス名 | segment header / data block / undo header / undo block 等で原因が変わる |
| Waits | 待機発生件数 | 多い場合は Segments by Buffer Busy Waits でオブジェクト特定 |
| Total Wait Time (s) | 累積待機時間（秒） | 0 秒なら実害なし。大きい場合はボトルネックとして扱う |
| Avg Time (ms) | 1回あたりの平均待機時間（ミリ秒） | 高い場合は競合が激しいホットブロックの可能性 |
6. PGA Aggr Target Stats— PGA集計対象統計
何を表すか: PGA の動作状況。PGA Cache Hit% / W/A MB Processed / PGA Target / Auto Target / PGA Alloc 等を Begin/End で表示。
- 読み方: PGA Cache Hit% = 100% は全ソート・ハッシュがメモリ内で完結（1-pass/M-passなし）。Extra W/A MB Read/Written > 0 なら Temp スピルが発生している。
- 閾値・注意点: PGA Cache Hit% < 100% で Extra W/A MB > 0 なら Temp スピルが発生しておりPGAサイズ拡大を検討。PGA Mem Alloc が PGA Target の 80% 超なら Target 増加を検討。
- 関連セクション: PGA Memory Advisory / Instance Efficiency (Optimal W/A Exec %)
- 使うシーン: PGA 不足・Temp スピルの確認
項目の意味と着目点 — PGA Aggr Target Stats
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| PGA Cache Hit % | Work Area 処理がメモリ内で完結した割合（%） | 100% が理想。低下している場合は Temp スピル発生中 |
| W/A MB Processed | Work Area で処理したデータ総量（MB） | ソート・ハッシュ・ビットマップ等の合計処理量 |
| Extra W/A MB Read/Written | Temp スピルにより追加で読み書きしたデータ量（MB） | 0 が理想。大きい場合は PGA 拡大または SQL のチューニングが必要 |
| PGA Aggr Target (M) | pga_aggregate_target の設定値（MB） | Begin/End が一致しない場合は動的変更が発生 |
| PGA Mem Alloc (M) | 全プロセスが実際に確保している PGA 総量（MB） | Target の 80% 超なら拡大を検討。Target を大幅に下回る場合は余裕あり |
| W/A PGA Used (M) | Work Area として使用中の PGA 量（MB） | 0 に近ければ現在 Work Area 処理が少ない |
7. PGA Aggr Target Histogram— PGA実行ヒストグラム
何を表すか: Work Area サイズ別の実行件数（Optimal / 1-Pass / M-Pass）。全実行が Optimal（メモリ内完結）かどうかを確認する。
- 読み方: 全行の 1-Pass Execs / M-Pass Execs = 0 なら完全なメモリ処理。特定サイズバケツで 1-Pass / M-Pass が多い場合はそのサイズ帯の Work Area が PGA 不足。
- 閾値・注意点: M-Pass（複数パス）が発生すると Temp 読み書きが増え、直接 I/O に影響する。大きなサイズバケツ（数百MB〜GB）で M-Pass が出る場合はソートや集計処理の改善を検討。
- 関連セクション: PGA Aggr Target Stats / PGA Memory Advisory
- 使うシーン: PGA サイジングの精密評価
項目の意味と着目点 — PGA Aggr Target Histogram
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Low Optimal / High Optimal | Work Area サイズのバケツ範囲（例: 64K〜128K） | 大きなバケツ（MB 単位）の値に着目する |
| Total Execs | そのサイズバケツでの総実行件数 | — |
| Optimal Execs | メモリ内で完結した実行件数（Optimal） | Total Execs と一致すれば全処理がメモリ内完結 |
| 1-Pass Execs | Temp を 1 回使用した実行件数 | 0 以外は軽度の PGA 不足 |
| M-Pass Execs | Temp を複数回使用した実行件数（重度スピル） | 0 以外は重大な PGA 不足。Temp I/O が大幅増加する |
8. PGA Memory Advisory— PGAメモリアドバイザ
何を表すか: pga_aggregate_target を現在値の 10%〜800% に変化させた場合の推定 Temp スピル量・処理時間・PGA Hit% を試算。
- 読み方: Estd PGA Overalloc Count = 0 になる最小の Target が推奨値。現在設定値で既に Overalloc=0 / Hit=100% であれば適正または余裕がある状態。
- 閾値・注意点: Overalloc Count = 0 を維持できる最小値が「必要十分な値」。削減する場合はピーク時の同時接続数・クエリ複雑度を考慮し、テスト環境での検証が必要。
- 関連セクション: PGA Aggr Target Stats / Memory Dynamic Components
- 使うシーン: PGA サイジング判断・削減検討
項目の意味と着目点 — PGA Memory Advisory
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| PGA Target (M) | 仮想的な pga_aggregate_target 値（MB） | Factr = 1.0 の行が現在設定値 |
| PGA Target Factr | 現在値に対する倍率 | 0.5 / 1.0 / 2.0 で効果の差を確認 |
| W/A MB Processed | 推定 Work Area 処理量（MB） | サイズに関わらず処理量は一定（変化しない） |
| Extra W/A MB Read/Written | Temp スピルによる追加 I/O 量（MB） | 0 になる最小 Target が推奨下限値 |
| Cache Hit % | 推定 Work Area のメモリ内完結率（%） | 100% を維持できる最小 Target がサイジング基準 |
| Overalloc Count | PGA Target を超過した推定件数 | 0 以外は PGA が実際の需要に追いついていない |
9. Process Memory Summary Stats— プロセスメモリ集計
何を表すか: 全プロセスの PGA 割当量を Alloc / Used / Freeable / Other / SQL / PL/SQL カテゴリで Begin/End 比較。最大 PGA を持つプロセスの上位リストも表示。
- 読み方: Freeable が大きいプロセスはメモリを確保しているが実際には使っていない状態（Oracle が解放可能と判断した領域）。Max Alloc が突出して大きいプロセスはメモリリークの可能性。
- 閾値・注意点: Hist Max Alloc と End Alloc の乖離が大きい場合は一時的に大量メモリを消費したプロセスが存在する。バックグラウンドプロセス（DBW0 / MMON 等）が上位にくるのは正常。
- 関連セクション: PGA Aggr Target Stats
- 使うシーン: PGA 消費の多いプロセス特定・メモリリーク調査
項目の意味と着目点 — Process Memory Summary Stats
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| PId | Oracle プロセス ID | V$PROCESS の SPID と照合してOS側プロセスを特定可能 |
| Process | プロセス名（DBW0 / MMON / J000 等） | バックグラウンドか Foreground（JDBC等）かで分析方向が変わる |
| Alloc (MB) | 確保している PGA 総量（MB） | Top プロセスの Alloc 合計が PGA Mem Alloc と照合できる |
| Used (MB) | 実際に使用中の PGA 量（MB） | Alloc との差が Freeable（未使用） |
| Freeable (MB) | 解放可能な PGA 量（MB） | 大きいほど確保しているが未使用の領域。リーク調査の糸口 |
| Max Alloc (MB) | スナップ期間中の最大 PGA 確保量 | End Alloc との差が大きい場合はピーク時に一時的な大量消費があった |