Backup, Recovery, and Flashback Fundamentals
This domain tests the difference between protecting a database and rewinding it: backup types, ARCHIVELOG implications, RMAN operations, and the several distinct Flashback technologies, each backed by a different mechanism.
Backup fundamentals
Physical backups are taken with RMAN or user-managed OS commands; logical backups use Data Pump. A consistent backup is taken with the database closed cleanly; an inconsistent backup is taken while open and needs archived redo to recover, so ARCHIVELOG mode is mandatory for online backups and point-in-time recovery. RMAN supports full and incremental backups, where level 0 is the incremental base and level 1 is cumulative or differential. Retention policies, autobackups of the control file and SPFILE, and channels are configured with CONFIGURE. The Fast Recovery Area, sized by DB_RECOVERY_FILE_DEST_SIZE, holds archived logs, backups, and flashback logs.
Flashback technologies
Flashback Query uses undo. Flashback Table also uses undo and requires row movement to be enabled. Flashback Drop reads the recycle bin and covers DROP TABLE only. Flashback Database uses flashback logs written by RVWR, requires ALTER DATABASE FLASHBACK ON and a mounted database, and is sized by DB_FLASHBACK_RETENTION_TARGET.
Worked example
A developer committed a DELETE without a WHERE clause thirty minutes ago on a small table. Reasoning: the before-images should still be in undo. Enable row movement with ALTER TABLE ... ENABLE ROW MOVEMENT, then FLASHBACK TABLE app.t TO TIMESTAMP. Flashback Database is the wrong tool here: it affects the whole database, requires flashback logs, and needs a mount. Restore-then-recover is the fallback if the undo is already gone.
Traps that cost marks
- Confusing RESTORE (copying files back) with RECOVER (applying redo and undo).
- Assuming the recycle bin protects against TRUNCATE; it does not.
- Believing Flashback Table relies on flashback logs rather than undo.