Buffer Cache Hit Ratioが99%近くても遅いという相談を受け、原因はPGAのTemp書き込みだったという経験があります。数値の高さだけで安心しないための読み方を整理しています。
メモリ問題の種類
図1: SGA/PGAメモリ問題の診断フロー
AWRで検出できるメモリ関連の問題は主に以下の3つです。
| 問題の種類 | 影響 | 見る場所 |
|---|---|---|
| Buffer Cache不足 | 物理I/O増加、db file読み取り待機増加 | Instance Efficiency / Buffer Cache Hit Ratio |
| PGA/ソートエリア不足 | 一時ディスクへのspill、direct path read temp | PGA Aggregate Statistics |
| 共有プール（Shared Pool）不足 | ハードパース増加、ライブラリキャッシュ競合 | Shared Pool Statistics / Library Cache Activity |
全体フローは PART 01、I/Oとの関係は PART 06 I/O分析 を参照。メモリ統計の定義は PART 06 — メモリ・I/O統計の見方（AWR入門） を参照。
Buffer Cache Hit Ratio の見方
Instance Efficiency Percentagesセクションにある Buffer Nowait % と Buffer Hit % が重要です。
| 指標 | 計算式 | 目安 |
|---|---|---|
| Buffer Hit % | 1 - (Physical Reads / Logical Reads) | 95%以上 |
| Library Cache Hit % | Pins / (Pins + Reloads) | 99%以上 |
| Shared Pool Free % | 共有プールの空き割合 | 10%〜30%を推奨 |
⚠️ Buffer Hit %の罠
Buffer Hit %が高くても、ブロック数自体が多い（Gets が膨大）場合は非効率なSQLがある可能性があります。絶対値（Gets/秒）も確認してください。
PGA統計の見方
PGA Aggregate Statisticsはソート・ハッシュ結合などのメモリ使用状況を示します。
% Optimal W/A Execs（最適実行の割合）が最重要指標です。
| 指標 | 意味 | 目安 |
|---|---|---|
| % Optimal W/A Execs | メモリ内で完結したワークエリア実行の割合 | 90%以上が理想 |
| % Onepass W/A Execs | 1回のディスクspillが発生した割合 | 多い場合はPGA不足 |
| % Multipass W/A Execs | 複数回のdisk spillが発生した割合 | 0%が理想 |
| Max PGA Target (MB) | PGAの最大割当量 | Multipas が多い場合は増加を検討 |
PGA/Advisoryの詳細は PART 07 — Advisory / Memory 詳細（定義書） を参照。
Advisory情報の活用
AWRの Advisory セクション（Buffer Pool Advisory / PGA Memory Advisory / SGA Target Advisory）は、 メモリサイズ変更時の効果をシミュレートした情報です。
| Advisoryの種類 | 活用方法 |
|---|---|
| Buffer Pool Advisory | Buffer Cache を増やした場合の物理読み込み削減効果を確認 |
| PGA Memory Advisory | PGA_AGGREGATE_TARGET 変更時のW/A実行比率改善効果を確認 |
| SGA Target Advisory | SGA全体サイズ変更時のDB Time改善効果を確認 |
メモリ診断でよくある誤り
メモリ増設を検討する前に、以下の誤診パターンに当てはまっていないか確認する。
| 誤りのパターン | なぜ誤りか | 正しい確認方法 |
|---|---|---|
| Buffer Hit %が95%以上なので問題なしと判断 | Gets/秒が膨大な場合はキャッシュ効率が良くても絶対I/O量が多い。SQLの非効率が隠れている | SQL StatisticsでGetsの多いSQLを確認し、インデックス見直しが先か判断する |
| % Multipass W/A Execsが出ているのでPGAを増やす | 巨大なソートを繰り返すSQLが原因の場合、PGA増加は一時解決にすぎない | 該当SQLの実行計画を確認。Hash Joinのメモリ消費量を見てSQLチューニングが先か判断 |
| Shared Pool Free %が低いのでShared Poolを増やす | バインド変数未使用によるハードパースが原因なら、Shared Pool増加は根本解決にならない | Hard Parsesをチェック。高ければバインド変数の使用がまず必要 |
| Advisory の推奨メモリを即そのまま適用する | Advisory はシミュレーションであり、物理メモリ全体やSGA/PGAのバランスを考慮していない | Advisory は参考値として使い、他の指標と合わせて設定値を決める |
サイジング改善の方向性
✅ メモリ改善の優先順位
① Buffer Cache Hit Ratioが低い → db_cache_size または sga_target の増加を検討
② % Multipass W/A Execs が 0より高い → pga_aggregate_target の増加を検討
③ Shared Pool Free % が低くハードパース多い → shared_pool_size の増加を検討
④ AMM/ASMM使用時は Advisory の推奨値を参考に memory_target を調整