Flashback Database can return existing database files to an earlier state after an unwanted logical change. It can be useful before a planned application change that affects many tables. The choice depends on the recovery scope, available history, required redo, feature eligibility, and storage capacity.
Oracle DBA Lesson 81 Part 3 — Database Flashback and Restore-Point Capacity
How database flashback reaches a target
Flashback Query and Flashback Table use undo. Flashback Database uses its own flashback logs, which contain earlier images of changed data file blocks. The logs are physical files in the fast recovery area (FRA) on disk.
During database flashback, Oracle restores earlier block versions into the existing data files and applies the required redo to reach the intended consistent system change number (SCN). That can avoid restoring those data files from backup for a logical rollback. Both the flashback history and the required online or archived redo must be accessible.
The selected scope returns to the target, so legitimate changes after that target are also affected. Database consistency does not restore external files, messages, remote systems, or other application side effects.
Flashback Database operates on existing data files. A missing file, a media failure, or physical damage needs an appropriate restore and recovery procedure, often with RMAN. Keep tested backups and their required recovery logs available independently. See Flashback Database and restore points and FLASHBACK DATABASE.
Normal and guaranteed restore points
| Property | Normal restore point | Guaranteed restore point |
|---|---|---|
| Target | A name associated with an SCN | A name associated with an SCN |
| Metadata | Recorded in the control file; ordinary points can age out | Remains until explicitly dropped |
| History | The name itself does not reserve the history needed to reach it | Required flashback history is retained, subject to documented prerequisites and limitations |
| Capacity consequence | No guaranteed retention obligation created by the name alone | Required history can prevent reuse and place pressure on the FRA |
A guaranteed restore point can support a return to that point even when full flashback logging is disabled. In RESTORE POINT ONLY mode, do not assume that every intermediate SCN is a direct flashback target. With full logging enabled, guaranteed-point retention can support a broader history interval. Verify the actual procedure and the required redo for the intended target.
The guarantee retains required history. It does not remove Flashback Database limitations. Shrinking a data file or dropping a tablespace can prevent the intended flashback. Restoring or recreating the control file discards accumulated flashback-log information. Review NOLOGGING activity and the other documented restrictions.
Check configuration, targets, and history
Flashback Database is an Enterprise Edition capability in the Oracle 19c licensing matrix. Support for Flashback Query does not establish eligibility for Flashback Database. This whole-database check reads the views from the CDB root. See licensing information.
SELECT flashback_on
FROM v$database;| FLASHBACK_ON | Interpretation |
|---|---|
| YES | Full flashback logging is enabled |
| NO | Flashback is off |
| RESTORE POINT ONLY | Flashback support is limited to guaranteed restore points |
Configuration is one input to the decision. Also check the history, redo, and restrictions for the specific target. See V$DATABASE.
SELECT name, scn,
guarantee_flashback_database AS guaranteed,
ROUND(storage_size / POWER(1024, 3), 1) AS storage_gib
FROM v$restore_point
ORDER BY time;| NAME | SCN | GUARANTEED | STORAGE_GIB |
|---|---|---|---|
| PRE_CHANGE_N | 7000 | NO | 0 |
| PRE_CHANGE_G | 7020 | YES | 40 |
The normal point PRE_CHANGE_N identifies SCN 7000. The guaranteed point PRE_CHANGE_G identifies SCN 7020 and has approximately 40 GiB of supporting disk space tied to it. STORAGE_SIZE is measured in bytes. The query converts it to GiB, where one GiB is 1,073,741,824 bytes.
STORAGE_SIZE is always zero for a non-guaranteed point. For a guaranteed point it estimates the space supporting that point. Supporting history can overlap across points, so those values are not independent reservations to add together. Dropping the oldest relevant point can remove a retention obligation. It does not promise immediate physical deletion of every supporting file. See V$RESTORE_POINT.
SELECT oldest_flashback_scn AS old_scn,
oldest_flashback_time AS old_time,
retention_target AS target_min,
ROUND(flashback_size / POWER(1024, 3), 1) AS flashback_gib
FROM v$flashback_database_log;| OLD_SCN | OLD_TIME | TARGET_MIN | FLASHBACK_GIB |
|---|---|---|---|
| 6900 | 22-OCT 08:00 | 1440 | 40 |
RETENTION_TARGET is in minutes. 1440 means one day. It expresses a desired window. Ordinary flashback history can be reused under space pressure, which shortens the available window. The oldest SCN and time describe retained flashback data. They do not by themselves establish that a particular recovery will succeed. Incarnation, required redo, configuration, file state, and scope still matter. See V$FLASHBACK_DATABASE_LOG and DB_FLASHBACK_RETENTION_TARGET.
Interpret recovery-area capacity
SELECT ROUND(space_limit / POWER(1024, 3), 1) AS limit_gib,
ROUND(space_used / POWER(1024, 3), 1) AS used_gib,
ROUND(space_reclaimable / POWER(1024, 3), 1) AS reclaimable_gib
FROM v$recovery_file_dest;| LIMIT_GIB | USED_GIB | RECLAIMABLE_GIB |
|---|---|---|
| 100 | 85 | 5 |
The quota is 100 GiB and 85 GiB is used, leaving 15 GiB currently unallocated. The reclaimable 5 GiB is part of the 85 GiB used. It is potential capacity after eligible files are removed, rather than another 5 GiB of already-free space. That potential capacity still depends on the applicable retention and backup conditions. See V$RECOVERY_FILE_DEST.
Those 40 GiB of protected history are already inside the 85 GiB used. The remaining 45 GiB is recovery-area space already in use for other files. If another 10 GiB of logs arrives and no space is reclaimed, used space reaches 95 GiB and only 5 GiB remains unallocated. This hypothetical growth step is not a measured rate or a forecast for every workload.
Also check free capacity on the underlying file system or ASM storage pool. A database quota does not create physical storage. SPACE_USED includes files created in the current and previous recovery areas. Changing the FRA location does not reset this counter to zero.
Required flashback logs cannot be discarded merely to relieve space pressure while they support a guaranteed restore point. Other eligible files may still be reclaimed under FRA rules. If the area fills and no files are eligible for removal or reuse, the database can encounter a disk-full condition and halt work.
For a change rehearsal, record:
- The actual scope and target, including which valid later work would be reversed.
- Eligibility,
ARCHIVELOGmode, the configured FRA, required history, and accessible redo. - Expected workload and log growth, existing retained obligations, policy headroom, and underlying storage capacity.
- A named operational role responsible for monitoring, an expiration time, and dropping the point when the rollback need ends.
- A tested backup fallback and the post-recovery application checks.
A guaranteed point kept indefinitely needs a capacity or cleanup owner. Dropping the point changes the recovery options. Do not delete required logs manually to force free space.
Scope and flashback conditions
A whole-CDB flashback affects its pluggable databases. A single-PDB flashback uses a supported PDB procedure and has scope-specific restore-point, undo-mode, and clean-restore-point requirements. In shared undo mode, clean PDB restore points are particularly important. Do not apply a root-level procedure blindly to a PDB.
Whole-database flashback normally requires the database mounted but not open, a current control file, ARCHIVELOG mode, a configured FRA, and the required administrative privilege in the correct scope. Reopening for writes after a database flashback requires OPEN RESETLOGS. Validate the target and the recovery result before that decision, and follow the backup strategy required for the new incarnation.
Recap
Flashback Database returns existing data files to an earlier SCN by using flashback logs and the required redo. A normal restore point names an SCN. A guaranteed restore point retains the history needed to reach it and can fill the FRA. Read FLASHBACK_ON, restore-point storage, the oldest flashback SCN, and unallocated quota, and count reclaimable space inside the used figure. Physical file loss needs restore and recovery.
No comments:
Post a Comment