共有プール（サイズ不足の兆候）難易度 高無料
本番システムで、同じ構造の SQL 文（リテラル値だけが異なりバインド変数化されていない）が大量に発行され続けた結果、共有プールの空き容量が逼迫し、既存のキャッシュ済みカーソルが頻繁に追い出される事象が発生した。この状況の説明として最も適切なものを選べ。（単一選択）
- Aバインド変数を使わずリテラル値を直接埋め込んだ SQL 文は、値が異なるたびに別の SQL 文として扱われて新規にハードパースされる。これが大量に発生すると共有プール（ライブラリキャッシュ）を圧迫し、他の解析済みカーソルの追い出しを招く
- Bこの現象はデータベースバッファキャッシュの不足が原因であり、共有プールとは無関係である
- Cリテラル値が異なっていても、SQL 文の構造（WHERE句の列やテーブル）が同じであれば Oracle は自動的に同一カーソルとして再利用するため、ハードパースは発生しない
- Dこの現象は REDOログバッファの不足が原因であり、
LOG_BUFFERの値を大きくすることで解決する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
共有プールのライブラリキャッシュは、SQL文のテキストが完全一致する場合にのみ解析結果（共有カーソル）を再利用できる（ソフトパース）。 リテラル値がそのまま埋め込まれた SQL（バインド変数を使わない SQL）は、値が変わるたびに別の SQL 文として扱われ、新規にハードパースされる。
この結果：
- 大量のユニークな SQL 文が次々とライブラリキャッシュに登録され、共有プールの空き容量を圧迫する。
- 空き容量が不足すると、Oracle は使用頻度の低いキャッシュ済みオブジェクト（他の解析済みカーソル等）をエイジアウト（追い出し）し、次回それらが必要になったときに再度ハードパースが発生する。
- これは典型的な「バインド変数の未使用によるライブラリキャッシュのスラッシング」であり、CPU 負荷増大とラッチ競合（library cache latch 等）を招く。
対策としては、アプリケーション側でバインド変数を使用する、または CURSOR_SHARING 初期化パラメータ（FORCE 等）でリテラルを自動的にバインド変数化する方法がある。
- B本問の現象（SQL カーソルの追い出し）はライブラリキャッシュ（共有プール）の圧迫が原因。バッファキャッシュはデータブロックのキャッシュであり、この事象の主因ではない。
- C既定（
CURSOR_SHARING=EXACT）では、リテラル値まで完全一致しないと同一カーソルとして再利用されない。構造が同じでも値が違えば別カーソル扱い。 - DREDOログバッファは変更内容を保持する領域であり、SQL 解析結果のキャッシュとは無関係。本事象の原因ではない。
ひっかけ： 「共有プールが小さいから増やせば根本解決する（サイズだけの問題）」という誤解。
SHARED_POOL_SIZE 拡大は緩和にはなるが、根本原因はバインド変数の未使用であり、サイズ拡大だけでは同じ問題が再燃し得る。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）