共有プール（ライブラリキャッシュ／データディクショナリキャッシュ）難易度 標準無料
あるセッションが SELECT * FROM hr.employees WHERE employee_id = 100; を初めて実行した際、Oracle は SQL 文を解析し、実行計画を生成した。同一の SQL 文（大文字小文字・空白まで完全一致）を別セッションが直後に実行したところ、解析コストが大幅に削減された（ソフトパース）。この挙動を支える共有プールの構成要素として最も適切なものを選べ。（単一選択）
- Aライブラリキャッシュ。解析済み SQL 文とその実行計画をキャッシュしており、完全一致の SQL 文が再実行されると解析・実行計画生成を省略できる（ソフトパース）
- Bデータベースバッファキャッシュ。SQL 文の解析結果ではなく、テーブルのデータブロックをキャッシュすることで再解析を省略する
- CREDOログバッファ。実行済み SQL の変更内容を保持しているため、同じ SQL の再解析が不要になる
- Dラージプール。RMAN バックアップや共有サーバーのセッションメモリ用の領域であり、通常の SQL 解析結果はここにキャッシュされない
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
共有プール（Shared Pool）は主に2つのキャッシュから構成される。
- ライブラリキャッシュ（Library Cache）：解析済みの SQL 文・PL/SQL プログラム単位（プロシージャ・パッケージ等）とその実行計画をキャッシュする。同一テキストの SQL 文が再実行されると、ハッシュ値で一致を検出し、構文解析・実行計画生成を省略（ソフトパース）できる。
- データディクショナリキャッシュ（行キャッシュ）：表・列・索引・権限などのメタデータ（データディクショナリの行）をキャッシュし、解析時にディクショナリ表への物理アクセスを減らす。
本問のように「完全一致の SQL 文の再実行でパースコストが下がる」現象は、ライブラリキャッシュに解析済みカーソル（共有カーソル）がヒットしたことによる。 なお SQL 文のテキストが1文字でも異なる（バインド変数化されていないリテラルの違い等）とハードパースになりやすい点も併せて押さえる。
- Bバッファキャッシュがキャッシュするのはデータブロックであり、SQL の解析結果ではない。パース省略に直接寄与するのはライブラリキャッシュ。
- CREDOログバッファは変更（REDO）を保持する領域であり、SQL 解析結果のキャッシュとは無関係。パース省略には関与しない。
- Dラージプールは RMAN・共有サーバー・並列問合せなど大きなメモリ割り当てが必要な用途向けの補助領域であり、通常の SQL 解析キャッシュの主体ではない。
ひっかけ： 「バッファキャッシュ（データブロックのキャッシュ）」との混同（B）。バッファキャッシュはデータブロック、ライブラリキャッシュはSQL/PL-SQLの解析結果という対象の違いを区別する。
公式ドキュメント・関連Database Concepts ― Shared Pool↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）