「メモリを増やせば直るはずです」と提案したのに、実際には改善しなかったことがあります。原因はBuffer Pool AdvisoryとShared Pool Advisoryの数値をきちんと根拠にしていなかったことでした。そのときの反省を踏まえ、数値に基づいた判断基準としてまとめています。
メモリ問題の種類
図1: STATSPACKでのメモリ問題診断
STATSPACKで検出できるメモリ関連の問題は主に以下の3つです。 Advisory情報が section/post-07（Buffer Pool / PGA）と section/post-10（SGA / Shared Pool）に分かれている点に注意してください。
| 問題の種類 | 影響 | 見る場所 |
|---|---|---|
| Buffer Cache不足 | 物理I/O増加、db file読み取り待機増加 | Buffer Hit % / Buffer Pool Advisory（定義書 PART 07） |
| Shared Pool不足 | ハードパース増加、ライブラリキャッシュ競合 | Shared Pool Advisory（定義書 PART 10） |
| PGA/ソートエリア不足 | 一時ディスクへのspill、direct path read temp | PGA / Memory Statistics（定義書 PART 07） |
全体フローは PART 01、I/Oとの関係は PART 06 I/O分析 を参照。
Buffer Cache / Buffer Pool Advisoryの見方
Buffer Pool Statistics（定義書 PART 07）でキャッシュ効率を確認し、 Buffer Pool Advisory（定義書 PART 07）でサイズ変更の効果をシミュレートします。
| 確認箇所 | 見る値 | 目安 |
|---|---|---|
| Instance Efficiency / Buffer Hit % | バッファキャッシュヒット率 | 95%以上。低い場合はcache増加を検討 |
| Buffer Pool Advisory / Est Phys Reads | キャッシュサイズ別の推定物理読み込み数 | Physical Reads が急減するサイズまでcacheを増やす |
| Buffer Wait Statistics / # Waits | バッファ待ち発生回数 | ゼロに近いほど良い。多い場合はLatch/Lock診断へ |
⚠️ Buffer Hit %の罠
Buffer Hit %が高くてもGets自体が膨大な場合は非効率なSQLがある可能性があります。絶対値（Logical Reads/s）も合わせて確認してください。
Shared Pool Advisoryの見方
Shared Pool Advisory（定義書 PART 10）はShared Pool（ライブラリキャッシュ + データディクショナリキャッシュ）のサイジング勧告です。
| 見る値 | 判断のポイント |
|---|---|
| Est Lib Cache Time Saved (s) | サイズを増やした場合のライブラリキャッシュ時間削減量。増加効果が大きいサイズに設定する |
| Estd Lib Cache Saved Factor | 現状比の改善倍率。1.0超なら増加効果あり |
詳細は PART 10 — SGA / Advisory / パラメータ（定義書） を参照。
SGA Target Advisoryの見方
SGA Target Advisory（定義書 PART 10）はSGA全体サイズ変更時の効果を示します。
AMM/ASMM使用時の sga_target チューニングに活用します。
| 見る値 | 判断のポイント |
|---|---|
| Est DB Time (s) | SGA Target 変更時の推定DB Time。最もDB Timeが低くなるサイズを選ぶ |
| SGA Size Factor | 現在のSGAサイズに対する比率 |
STATSPACKメモリ診断でよくある誤り
Advisory情報が複数セクションに分かれるSTATSPACKでは、AWR以上に誤診が起きやすい。代表的な落とし穴を整理する。
| 誤りのパターン | なぜ誤りか | 正しい確認方法 |
|---|---|---|
| Buffer Hit %が高いのでBuffer Cacheは十分と判断する | Gets/sが非常に多い場合は非効率なSQLが存在しているサイン。キャッシュ効率が高くても絶対I/O量が多い | SQL ordered by Logical ReadsでGetが多いSQLを確認。SQLチューニングが先か判断する |
| Shared Pool Advisory が「増加効果あり」なのですぐ増やす | Hard Parses/sが高い場合は、バインド変数未使用が原因であり、Shared Pool増加は一時凌ぎにすぎない | Hard Parsesの値を確認。高い場合はアプリ側のバインド変数対応を先に実施 |
| direct path read tempが出たのでPGAを増やす | 一部の巨大ソートSQLだけが原因の場合、PGA全体を増やしても効果が薄い場合がある | SQL ordered by Elapsed Timeとdirect path read tempの多いSQLを突き合わせてSQL単体のソートメモリ消費を見る |
サイジング改善の方向性
✅ メモリ改善の優先順位
① Buffer Hit % が低い → db_cache_size または sga_target の増加
② Library Hit % が低い / Hard Parse多い → shared_pool_size の増加
③ direct path read temp が多い → pga_aggregate_target の増加
④ SGA Target Advisory でDB Timeが改善するサイズに sga_target を調整