フラッシュバック（Flashback Drop / リサイクルビン）難易度 標準無料
ユーザー表領域上の表 hr.emp を誤って DROP した。リサイクルビンは有効（recyclebin=on・既定）である。次のいずれの操作で消したかで復旧可否が変わる。
-- ケース1 SQL> DROP TABLE hr.emp; -- ケース2 SQL> DROP TABLE hr.emp PURGE;
Flashback Drop とリサイクルビンの挙動として最も適切なものを選べ。（単一選択）
- Aケース1（
DROP TABLE）はリサイクルビンへ移動されるのでFLASHBACK TABLE hr.emp TO BEFORE DROP;で復元できるが、ケース2（PURGE）はリサイクルビンを経由せず即完全削除されるためTO BEFORE DROPでは戻せない - Bケース1・ケース2 とも表はリサイクルビンに入るので、どちらも
TO BEFORE DROPで戻せる - CFlashback Drop はフラッシュバックログ（
FLASHBACK ON）を必要とし、有効化していないとTO BEFORE DROPは失敗する - Dケース1 でも表は即座に物理削除され領域も解放されるため、
TO BEFORE DROPは常に領域不足で失敗する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・AIで再検証済
解説
リサイクルビンが有効なとき、通常の DROP TABLE（ケース1）は表を即時に物理削除せず、リサイクルビンへ移動（BIN$... にリネーム）する。
占有領域は保持されたままなので、FLASHBACK TABLE hr.emp TO BEFORE DROP; で元に戻せる。
一方 DROP TABLE ... PURGE（ケース2）はリサイクルビンを経由せず即座に完全削除する。リサイクルビンに入らないため、
TO BEFORE DROP では戻せない（この場合の復旧は、より重い時点指定リカバリ等に頼ることになる）。
補足：リサイクルビンはユーザー表領域のオブジェクトが対象で、SYSTEM 表領域のオブジェクトは対象外。領域が逼迫すると、リサイクルビン内のオブジェクトは古い順に自動的に追い出され得る（＝いつまでも戻せる保証はない）。
- B
PURGEはリサイクルビンを経由しないため、ケース2 はTO BEFORE DROPで戻せない。両方戻せるは誤り。 - CFlashback Drop が使うのはリサイクルビンで、フラッシュバックログ（Flashback Database 用）は不要。前提を取り違えている。
- D通常の
DROPでは領域はすぐ解放されず、リサイクルビンに保持される。だからこそTO BEFORE DROPで戻せる（領域逼迫で追い出される前なら）。
ひっかけ：
PURGE の有無で TO BEFORE DROP の可否が分かれる点が核心。
また Flashback Drop（リサイクルビン）と Flashback Table（UNDO で TO TIMESTAMP）の混同、フラッシュバックログ（Flashback Database）との取り違えにも注意。コマンド例と想定される挙動（未実行）
DROP TABLE hr.emp; → リサイクルビンへ（FLASHBACK TABLE hr.emp TO BEFORE DROP; で復元）。 DROP TABLE hr.emp PURGE; → 即完全削除（TO BEFORE DROP 不可）。
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）