# 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: ```plaintext 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](https://jhdba.wordpress.com/2010/01/06/flashback-disabled-automatically-a-minor-rant/) 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](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/using-flasback-database-restore-points.html#GUID-E90F7FBD-CCE2-4234-A3B4-FDFEC3BC2E90) 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) ```plaintext 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: ```plaintext 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): ```plaintext [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)): ```plaintext [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: ```plaintext 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: ```plaintext 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: ```plaintext 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. ```plaintext 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: ```plaintext 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.