Oracle Flashback Database Automatic Deactivation
Today I learned that Oracle can disable the Flashback Database feature by itself automatically. Here's the reason - an excerpt from the alert log:
ORA-38886: WARNING: Flashback database was disabled due to error when writing flashback database logs.
Apparently, this is not a new behavior, as there's a blog post about it from the year 2010 by John Hallas.
But there have been improvements since he wrote this post. In 19c, the flashback logging (alter database flashback on/off) can be executed while the database is in READ WRITE state (no need to bounce it anymore).
I also agree with John that a parameter, which would cause flashback to behave similarly to a MANDATORY archivelog destination, would be a welcome addition. To my knowledge, such a parameter does not exist.
Official Docs
Here's what the official docs say about that:
The following rules govern creating, retaining, overwriting and deleting of flashback logs in the fast recovery area:
If the fast recovery area has enough space, then a flashback log is created whenever necessary to satisfy the flashback retention target.
If a flashback log is old enough that it is no longer needed to satisfy the flashback retention target, then the flashback log may be reused or deleted.
If the database must create a flashback log and the fast recovery area is full or there is no disk space, then the oldest flashback log is reused instead.
Test Cases
I decided to create a test case to replicate the issue of flashback disabling itself. According to the docs, it shouldn’t easily happen due to space pressure, except, it seems, if there are actual I/O errors due to out-of-space conditions.
In both test cases, there were no Restore Points in use (empty v$restore_point).
Case 1: mountpoint (2G) smaller than db_recovery_file_dest_size (10G)
NAME VALUE COMMENT
------------------------------ --------------- ----------
db_recovery_file_dest /fra 2 GB
db_recovery_file_dest_size 10737418240 10 GB
db_flashback_retention_target 1440 24 h
FLASHBACK_ON LOG_MODE
------------------ ------------
YES ARCHIVELOG
On the first try, when the space ran out, I got this in the alert log:
2025-09-25T23:01:41.098262+02:00
Errors in file /oracle/diag/rdbms/orcl/orcl/trace/orcl_gen0_1207793.trc:
ORA-38701: Flashback database log 10 seq 1 thread 1: "/fra/ORCL/flashback/o1_mf_nfccfnv4_.flb"
ORA-27072: File I/O error
Additional information: 4
Additional information: 1153
Additional information: 90112
2025-09-25T23:01:41.098454+02:00
Deleted Oracle managed file /fra/ORCL/flashback/o1_mf_nfccfnv4_.flb
But it did not stop the database from continuing to work. The only side effect was, as documented, V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_TIME shifted forward as the oldest flb log(s) got deleted (the docs say “reuse,” but according to this test case, old ones are deleted so that new ones can appear).
Note that df reported a little bit of space still left (~9mb):
[root@db-server fra]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdg 2.0G 1.8G 9.1M 100% /fra
So, I decided to use dd to ensure there is absolutely no space left (by creating dummy file(s)):
[root@db-server fra]# df -h /fra
Filesystem Size Used Avail Use% Mounted on
/dev/sdg 2.0G 1.9G 0 100% /fra
Finally I got:
Errors in file /oracle/diag/rdbms/orcl/orcl/trace/orcl_gen0_1207793.trc:
ORA-38701: Flashback database log 10 seq 1 thread 1: "/fra/ORCL/flashback/o1_mf_%u_.flb"
ORA-27044: unable to write the header block of file
Linux-x86_64 Error: 28: No space left on device
And a bit later, finally:
ORA-38886: WARNING: Flashback database was disabled due to error when writing flashback database logs.
ORA-38701: Flashback database log 10 seq 12 thread 1: "/fra/ORCL/flashback/o1_mf_%u_.flb"
ORA-27044: unable to write the header block of file
Linux-x86_64 Error: 28: No space left on device
And, to confirm that it was actually disabled:
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
Case 2: mountpoint (2G) > db_recovery_file_dest_size (1G)
Now, given the observations from the first case, I would imagine that this only happens on an OS-level error. The chance of an out-of-space OS error occurring is much smaller if db_recovery_file_dest_size is correctly configured—not like I did in the previous case just to prove a point.
NAME VALUE GB_VALUE
------------------------------ --------------- ----------
db_recovery_file_dest /fra
db_recovery_file_dest_size 1073741824 1
db_flashback_retention_target 1440
Now, we do get a warning like this, but nothing is disabled because of space pressure:
ORA-19815: WARNING: db_recovery_file_dest_size of 1073741824 bytes is 93.69% used, and has 67731456 remaining bytes available.
2025-09-25T23:48:47.961667+02:00
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Reclaimable space = 0
Available space = 67731456
Disk space limit = 1073741824
See trace file /oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_1211049.trc for usage information from V$RECOVERY_AREA_USAGE
I’ve let redo be generated for about 24h straight, and even after RVWR wrote about 50GB of data, the FRA (Fast Recovery Area) did not get disabled and no out-of-space errors occurred.
How to Avoid
Having sufficient space for your FRA and maybe adding an additional check to your monitoring system (which is what we just did) is probably the safest bet.
Also, as demonstrated, having a dedicated mount point (or ASM disk group) for db_recovery_file_dest and having a correctly configured db_recovery_file_dest_size can significantly reduce the chance of this happening.
For monitoring purposes, you might want to distinguish between databases where Flashback was previously enabled (and later disabled) versus databases where it was never enabled (nor intended to). Based on my limited testing on 19.28.0, I observed an interesting pattern: when Flashback Database is disabled, Oracle removes the oracle-managed files but leaves behind an empty ./flashback/ directory within the FRA. In contrast, databases that never had Flashback enabled don't have this directory at all.
Important caveat: This is my preliminary observation based on a quick test and should be validated more thoroughly before relying on it for monitoring.