Oracle problems

Oracle FRA Full: ORA-00257, What Fills the Fast Recovery Area, and How to Clear It Safely

2 November 2026

When the fast recovery area is full, the archiver stops, the redo logs cannot switch, and every session that writes waits on log file switch (archiving needed). The database is up, and nobody can commit. It is the most avoidable outage in Oracle, because the area fills at a rate you can measure days ahead.

What the errors say

• ORA-00257: Archiver error. Connect AS SYSDBA only until resolved. The archiver could not write the next archived log. Users get it at logon; sessions already connected hang at the next log switch.
• ORA-19815: WARNING: db_recovery_file_dest_size of N bytes is 97.00% used, in the alert log, hours or days before. It even lists what to do, and nobody reads it, because it is a warning in a log.
• ORA-19809: limit exceeded for recovery files and ORA-19804: cannot reclaim N bytes disk space from M bytes limit: the same condition, as RMAN and the archiver see it.

The limit is db_recovery_file_dest_size, a quota that you set, not the disk. The disk can have a terabyte free while the quota is 100 GB and full. That is also what makes the first fix so fast.

What is in it

SELECT name,
       ROUND(space_limit       / POWER(1024, 3), 1) AS limit_gb,
       ROUND(space_used        / POWER(1024, 3), 1) AS used_gb,
       ROUND(space_reclaimable / POWER(1024, 3), 1) AS reclaimable_gb,
       ROUND((space_used - space_reclaimable)
             / space_limit * 100)                   AS pct_used_net,
       number_of_files
FROM   v$recovery_file_dest;

SELECT file_type, percent_space_used, percent_space_reclaimable,
       number_of_files
FROM   v$recovery_area_usage
ORDER  BY percent_space_used DESC;

Reclaimable is space that Oracle takes back by itself when it needs it: archived logs that are backed up, obsolete backups, flashback logs beyond the retention. A FRA at 90% used with 60% reclaimable works as designed. pct_used_net is the real number.

The restore points, the archive destinations and the sessions that wait:

SELECT name, time, guarantee_flashback_database,
       ROUND(storage_size / POWER(1024, 3), 1) AS gb
FROM   v$restore_point;

SELECT dest_id, dest_name, status, target, error
FROM   v$archive_dest
WHERE  status <> 'INACTIVE';

SELECT inst_id, COUNT(*) AS sessions_waiting
FROM   gv$session
WHERE  event = 'log file switch (archiving needed)'
GROUP  BY inst_id;

Fix it, in this order

1. Raise the quota, now. If the disk has room, one statement unblocks the database and buys the time to do the rest properly:

   ALTER SYSTEM SET db_recovery_file_dest_size = 400G SCOPE=BOTH;

   The archiver retries by itself. Nothing is lost, nothing is deleted, and no restart is needed.
2. Back up the archived logs and let RMAN delete them.

   RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;
   RMAN> DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE sbt;

   With a standby, make the deletion policy say what it protects: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;. Then a log that the standby has not applied stays, and the fix is the standby, not the FRA.
3. Drop the forgotten restore point. DROP RESTORE POINT before_release; makes the flashback logs it kept reclaimable at once.
4. Delete obsolete backups. RMAN> CROSSCHECK BACKUP; DELETE OBSOLETE; under the retention policy you configured.
5. Never delete the files at the operating system. Oracle still counts them, so the area stays full until CROSSCHECK ARCHIVELOG ALL; DELETE EXPIRED ARCHIVELOG ALL;. And an archived log deleted before its backup is a hole in your recovery.

See it coming

A FRA fills at the rate of the redo plus the backups minus the deletes, and that rate is stable from week to week. Radar Engine, the detection layer of Scops, watches it as a countdown and crosses it with the backup jobs:

The combination is the point. A FRA at 70% is nothing. A FRA at 70% whose archivelog backup has not moved for three hours is tonight's outage, and Radar reports that as one Critical finding, not as two Watches on two screens. With the OS credential of the database, the log detectors report a stuck archiver from the alert log as Critical the first time it appears.

Questions

Can I delete old archived logs to free the FRA?
Through RMAN, yes: DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE sbt deletes what is backed up. Not at the operating system: Oracle keeps counting the files until a CROSSCHECK, and a log deleted before its backup breaks the recovery.

Why is the FRA full when the disk has plenty of space?
The FRA is limited by db_recovery_file_dest_size, a quota, not by the disk. Raise the quota with ALTER SYSTEM; it takes effect at once.

Why does RMAN not delete archived logs that are backed up?
The deletion policy keeps logs a standby has not applied, a guaranteed restore point keeps flashback logs, and a backup without DELETE INPUT deletes nothing. V$RECOVERY_AREA_USAGE shows which file type holds the space.

Does raising db_recovery_file_dest_size need a restart?
No. ALTER SYSTEM SET db_recovery_file_dest_size with SCOPE=BOTH applies at once, and the archiver continues by itself.

Related problems

• RMAN backup failed or overdue
• Data Guard standby lag and gap
• Tablespace full: ORA-01653
• ORA-00020: maximum number of processes
• Log file switch (checkpoint incomplete)
• Archiver stuck: ORA-16014
• All Oracle problems

Sources

• Oracle: ORA-00257, ORA-19815, ORA-19809
• Oracle: V$RECOVERY_FILE_DEST, V$RECOVERY_AREA_USAGE, V$RESTORE_POINT
• Scops docs: Detector reference