Examine the statements that use flashback technologies: 1. FLASHBACK TABLE customers TO TIMESTAMP TO_TIMESTAMP (2013-02-04 09:30:00, YYYY-MM-DD HH:MI:SS); 2. SELECT FROM customers AS OF SCN 123456…

Question

Options

• A1,3,6
• B1,2,5
• C3,4,5
• D2,3,5,6

• A
  23% (14)
• B
  58% (35)
• C
  12% (7)
• D
  7% (4)

Explanation

Option B is correct because statements 1, 2, and 5 all rely on Oracle's undo tablespace to reconstruct past row images. FLASHBACK TABLE ... TO TIMESTAMP (1) uses undo to reverse DML changes; SELECT ... AS OF SCN (2) is a Flashback Query that reads historical row versions from undo; and SELECT ... VERSIONS BETWEEN SCN (5) is a Flashback Versions Query that mines undo for all row changes across a range.

Why the distractors fail:

• Statement 3 (TO BEFORE DROP) uses the Recycle Bin, not undo - it simply undrops the table object.
• Statement 4 (FLASHBACK DATABASE) uses Flashback Logs stored in the Fast Recovery Area (FRA), not undo.
• Statement 6 (ALTER TABLE ... FLASHBACK ARCHIVE) enables Flashback Data Archive, which stores history in a dedicated archive tablespace, completely independent of undo retention.

This eliminates A (wrongly includes 3 and 6), C (wrongly includes 3 and 4), and D (wrongly includes 3 and 6).

Memory tip: Think of undo-dependent flashback as row-level time travel - any feature that reconstructs row data on the fly (Flashback Query, Versions Query, Table-to-timestamp) needs undo. Features with their own dedicated storage (Recycle Bin for dropped objects, FRA logs for the whole database, Archive tablespace for long-term history) are self-contained and undo-independent.

No community discussion yet for this question.