Flashback Database, Flashback Logs, Guaranteed Restore Points, and Operational Tradeoffs

Learning outcomes

A bad deployment updates thousands of tables across the ServiceHub CDB. Table-by-table repair would be error-prone, but the datafiles are healthy and the problem was discovered quickly. Flashback Database can physically rewind data blocks using flashback logs and then use redo to reach the exact target, often avoiding a full backup restore. The speed comes with a price: flashback logging consumes write bandwidth and recovery storage, and a guaranteed restore point can pin that storage until explicitly dropped.

1. Flashback Database is physical recovery without restoring datafiles

Flashback Database stores before-images/change information in flashback logs. The Recovery Writer process (RVWR) writes the flashback logging stream. To rewind, Oracle uses flashback logs to move datafiles backward and archived/online redo to reconcile the target point. The result resembles database point-in-time recovery, but avoids restoring all datafiles from backup when the flashback window is intact.

Flashback Database is available in current Oracle AI Database Free. It still requires operational preparation: ARCHIVELOG mode, a Fast Recovery Area (FRA), current control-file history, and flashback logging before the target—unless rewinding specifically to a guaranteed restore point that retained what is required.

2. Mandatory read-only preflight

ALTER SESSION SET CONTAINER=CDB$ROOT;SELECT  name,  log_mode,  flashback_on,  current_scnFROM v$database;SELECT name,value,ispdb_modifiableFROM v$parameterWHERE name IN (  'db_recovery_file_dest',  'db_recovery_file_dest_size',  'db_flashback_retention_target',  'db_flashback_log_dest',  'db_flashback_log_dest_size')ORDER BY name;SELECT  space_limit,  space_used,  space_reclaimable,  number_of_filesFROM v$recovery_file_dest;

If FLASHBACK_ON=NO, ordinary flashback logs are not being generated for a normal flashback window. Do not turn the feature on just to complete the mandatory read-only exercise; enabling it is a CDB-level durability/performance/storage policy change.

3. Observe the actual flashback window and estimated space

SELECT  oldest_flashback_scn,  oldest_flashback_time,  retention_target,  flashback_size,  estimated_flashback_sizeFROM v$flashback_database_log;SELECT *FROM (  SELECT    begin_time,    end_time,    flashback_data,    db_data,    redo_data,    estimated_flashback_size  FROM v$flashback_database_stat  ORDER BY end_time DESC)FETCH FIRST 12 ROWS ONLY;

DB_FLASHBACK_RETENTION_TARGET is a target, not a guarantee. Under FRA space pressure, old non-guaranteed flashback logs can be deleted. The actual reachable window is represented by OLDEST_FLASHBACK_SCN/TIME.

4. 26ai can place flashback logs outside the FRA

Oracle AI Database 26ai introduces DB_FLASHBACK_LOG_DEST and DB_FLASHBACK_LOG_DEST_SIZE. They allow flashback logs to use a separately sized, potentially faster disk location while backups/archived redo remain in the FRA. The parameters are instance/CDB-level and not PDB-modifiable.

SELECT  name,  space_limit,  space_used,  number_of_filesFROM v$flashback_log_dest;

A configured separate destination can reduce competition with FRA files, but moving to it requires disabling/re-enabling flashback logging around the parameter change. That is maintenance, not an online “point this to faster disk” tweak.

5. Normal restore points are SCN labels

A normal restore point gives a stable name to an SCN/time. It does not by itself force Oracle to retain every flashback log needed forever. If normal flashback history ages out, the label can still exist while Flashback Database cannot reach it.

CREATE RESTORE POINT sh16_normal_marker;SELECT  name,  scn,  time,  guarantee_flashback_database,  storage_size,  preservedFROM v$restore_pointWHERE name='SH16_NORMAL_MARKER';DROP RESTORE POINT sh16_normal_marker;

This lab changes only restore-point metadata and does not rewind data.

6. Guaranteed restore points pin flashback capability and storage

A guaranteed restore point (GRP) causes Oracle to retain enough flashback logging to return the database to that restore point. The CDB must be in ARCHIVELOG mode and an FRA must exist; Flashback Database itself does not need to have been enabled before creation of the GRP. GRPs never age out and must be explicitly dropped.

CREATE RESTORE POINT sh16_before_risky_change  GUARANTEE FLASHBACK DATABASE;SELECT  name,  scn,  guarantee_flashback_database,  storage_size,  preservedFROM v$restore_pointWHERE name='SH16_BEFORE_RISKY_CHANGE';-- After the risk window is closed and rollback is no longer needed:DROP RESTORE POINT sh16_before_risky_change;

STORAGE_SIZE approximates bytes tied up by the restore point that would become reclaimable if the oldest GRP were dropped. A forgotten GRP can fill the FRA and threaten archive/backup activity.

7. Optional full flashback workflow: whole disposable CDB only

-- Before the risky change:CREATE RESTORE POINT sh16_before_change  GUARANTEE FLASHBACK DATABASE;-- ...perform disposable test changes...SHUTDOWN IMMEDIATE;STARTUP MOUNT;FLASHBACK DATABASE TO RESTORE POINT sh16_before_change;ALTER DATABASE OPEN RESETLOGS;DROP RESTORE POINT sh16_before_change;

If the database is not in normal FLASHBACK mode, Flashback Database can only rewind to a suitable guaranteed restore point. OPEN RESETLOGS creates a new incarnation context and must feed back into the RMAN backup/recovery plan.

8. PDB flashback narrows the logical tenant scope

Current 26ai supports FLASHBACK PLUGGABLE DATABASE and PDB restore points. It can rewind one PDB without changing the other PDBs, subject to local/shared undo, restore-point, redo, and current-control-file prerequisites. Use PDB-level recovery when the incident is isolated to one tenant and dependency/application semantics permit it.

9. Deliberately wrong: create a GRP before every deploy and never drop it

GRPs are preserved and can retain large amounts of flashback data. The FRA may fill even though ordinary retention would have deleted older flashback logs. The repair is lifecycle ownership: create the GRP immediately before a defined risky window, monitor storage, test rollback, and explicitly drop the GRP when the rollback decision closes.

SELECT  name,  time,  guarantee_flashback_database,  storage_size,  preservedFROM v$restore_pointORDER BY time;SELECT  space_limit,  space_used,  space_reclaimableFROM v$recovery_file_dest;

10. Performance evidence matters

Flashback logging adds write I/O. Oracle recommends baselining the workload before enabling the feature and monitoring flashback-log generation plus I/O waits. On a slow flashback-log destination, the RVWR path can become a workload bottleneck; 26ai's separate flashback-log destination exists partly to isolate this pressure.

SELECT event,total_waits,time_waited_microFROM v$system_eventWHERE LOWER(event) LIKE '%flashback%'ORDER BY time_waited_micro DESC;

11. Production judgment

Enable Flashback Database when fast reversal of recent widespread logical errors materially improves RTO and storage/I/O can support the retention target. Use GRPs only for explicit high-risk windows and monitor their storage. Keep tested RMAN backups because flashback logs live in the same database recovery ecosystem and can be lost, aged out, or invalidated by control-file/media events.

Flashback Database is available in current Free; no management pack is required. PDB restore points require documented multitenant prerequisites, and the 26ai separate flashback-log destination is a current-version feature. Lesson 5 closes the chapter by moving from short operational windows to long-term retained row history.

Authoritative references

• Using Flashback Database and Restore Points — flashback logging, restore points and monitoring
• FLASHBACK DATABASE — database rewind prerequisites/syntax
• CREATE RESTORE POINT — normal/guaranteed restore-point semantics
• DB_FLASHBACK_LOG_DEST — 26ai separate log destination
• Licensing Information — Flashback Database availability