データベースバッファキャッシュ難易度 標準無料
セッションが UPDATE hr.employees SET salary = salary * 1.05 WHERE department_id = 90; を実行して COMMIT; した直後の、データベースバッファキャッシュ内の該当ブロックの状態として最も適切なものを選べ。（単一選択）
- A該当ブロックはバッファキャッシュ内でダーティブロックとしてマークされたままである可能性が高く、
COMMIT自体はデータファイルへの即時書き戻しを保証しない。ディスクへの反映は DBWn が別途行う - B
COMMITの完了と同時に、Oracle はそのブロックを必ずディスクのデータファイルへ書き戻してから制御を戻す - COracle には「ダーティブロック」という概念は存在せず、変更されたブロックも未変更ブロックと区別なくバッファキャッシュに保持される
- Dダーティブロックは
COMMITと同時にバッファキャッシュから即座に削除（エイジアウト）され、以後は必ずディスクから再読込される
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
データベースバッファキャッシュは、ディスクから読み込んだデータブロックのコピーを保持する SGA の領域である。 ブロックには ピンされている／使用されていない（unused） といった状態のほか、変更を受けたブロックはダーティ（dirty）としてマークされる。
UPDATE によってメモリ上のブロックが変更されると、そのブロックはダーティブロックになる。
変更内容はまず REDOログバッファに記録され、COMMIT 時に LGWR が REDOログファイルへ書き込むが、
データブロック自体（バッファキャッシュ内のダーティブロック）をディスクのデータファイルへ書き戻すのは DBWn の仕事であり、COMMIT のタイミングとは非同期である。
つまり、COMMIT 直後でも、そのダーティブロックはまだバッファキャッシュに残ったまま（ディスクへの書き戻し未完了）であることが多い。
これが Oracle の「高速コミット（fast commit）」の仕組み＝コミット時に保証されるのは REDOログの永続化であって、データファイルへの即時反映ではないという重要な性質である。
- B
COMMITが同期的に保証するのは REDOログの書き込みであり、データブロックのディスク書き戻しではない。書き戻しは DBWn が非同期に行う。 - C変更を受けたブロックは明確にダーティブロックとして区別・管理される（DBWn の書き出し対象を判別するために必要な区分）。
- D
COMMITでブロックが即座にキャッシュから削除されるわけではない。LRU アルゴリズムに基づき、必要になるまでキャッシュに残り続けることが多い。
ひっかけ： 「COMMIT ＝ ディスクのデータファイルに即座に反映される」という誤解（B・C）が最頻出。COMMIT が保証するのは REDOログの書き込みであり、
データブロックのディスク反映（DBWn によるチェックポイント／LRU 契機の書き出し）は別のタイミングで非同期に行われる。
公式ドキュメント・関連Database Concepts ― Database Buffer Cache↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）