Oracle Flashback Database: Why It Can Disable Itself Automatically
When Flashback Turns Itself Off — A Closer Look
Under certain conditions, Oracle can automatically disable Flashback Database. While this behavior is not entirely new (there are posts from 2010 on the topic), it's useful to revisit with respect to newer versions like 19c, which allow toggling Flashback on/off even in READ WRITE
mode (no restart needed).
What Got Me Interested
ORA-38886: WARNING: Flashback database was disabled due to error when writing flashback database logs.
This prompted me to explore the scenarios under which Oracle might disable Flashback on its own.
Flashback Behavior: A Quick Recap
- Flashback logs are generated as needed, provided there’s available space in the Fast Recovery Area (FRA).
- Logs older than the retention target can be deleted or reused.
- If the FRA is full, Oracle may reuse the oldest flashback logs.
- If there’s absolutely no space or an I/O error occurs, Flashback can be disabled automatically.
Test Case 1: FRA Mount Point Smaller than db_recovery_file_dest_size
db_recovery_file_dest = /fra
db_recovery_file_dest_size = 10 GB
db_flashback_retention_target = 1440 (24 hrs)
FLASHBACK_ON = YES
LOG_MODE = ARCHIVELOG
db_recovery_file_dest = /fra
db_recovery_file_dest_size = 10 GB
db_flashback_retention_target = 1440 (24 hrs)
FLASHBACK_ON = YES
LOG_MODE = ARCHIVELOG
Mount /fra
was limited to 2 GB, far below the 10 GB target. As the disk filled, Oracle logged I/O errors such as:
ORA-27072: File I/O error
The database continued to run, deleting older flashback logs. The OLDEST_FLASHBACK_TIME
in V$FLASHBACK_DATABASE_LOG
advanced. When I forced the mount to zero free space, the alert log showed:
ORA-27044: unable to write the header block of file
Linux-x86_64 Error: 28: No space left on device
ORA-38886: WARNING: Flashback database was disabled …
Querying the status:
SELECT flashback_on FROM v$database;
Result:
FLASHBACK_ON
------------------
NO
Test Case 2: FRA Mount Point Larger than db_recovery_file_dest_size
db_recovery_file_dest = /fra
db_recovery_file_dest_size = 1 GB
Mount point size = 2 GB
db_recovery_file_dest = /fra
db_recovery_file_dest_size = 1 GB
Mount point size = 2 GB
Even after generating ~50 GB of redo, Oracle only issued warnings such as:
ORA-19815: db_recovery_file_dest_size is 93.69% used
Flashback remained enabled. This shows that space pressure alone won’t disable Flashback—it requires actual I/O write failures.
Key Observations & Best Practices
- Allocate adequate space for FRA, aligned with recovery and flashback targets.
- Use dedicated mount points or ASM disk groups to isolate FRA.
- Actively monitor FRA usage and flashback status.
- Note: when Flashback is disabled, Oracle removes
.flb
files, but the /flashback/
directory (empty) may remain.
.flb
files, but the /flashback/
directory (empty) may remain.Final Thoughts
It would be ideal if Oracle treated Flashback like a mandatory archive destination—preventing the database from silently disabling it. As of version 19.28.0, no such feature exists. Until then, careful space planning, monitoring, and proactive alerting are the best defense against surprises.
No comments:
Post a Comment