Oracle Fast Recovery Area full: db_recovery_file_dest_size, reclaimable space, and DELETE OBSOLETE

The Fast Recovery Area (FRA) is Oracle’s self-managing location for recovery-related files: archived redo logs, RMAN backups, flashback logs, and control file autobackups. Its size is bounded by the DB_RECOVERY_FILE_DEST_SIZE parameter, a hard quota Oracle enforces internally on the total bytes these files can occupy.

When the FRA fills, every consumer that writes to it stalls at once. ARCn cannot write archived redo logs. RMAN backups fail. Flashback log creation fails. The most dangerous consequence is the archive stall: online redo logs cannot be reused until they are archived, so LGWR eventually cannot switch to a new log group, and every session that needs to generate redo freezes.

This failure mode masquerades as “database up.” The instance remains OPEN. The listener responds. Existing sessions do not get an error returned to the client; they hang on log file switch (archiving needed). New non-SYSDBA connections receive ORA-00257. Health checks that only run SELECT statements may pass because reads do not generate redo. The database is alive and completely unresponsive.

What this means

The FRA quota is exposed through V$RECOVERY_FILE_DEST in four columns: SPACE_LIMIT (configured size), SPACE_USED (current consumption), SPACE_RECLAIMABLE (bytes Oracle believes it can free by deleting obsolete or redundant files), and NUMBER_OF_FILES.

When SPACE_USED approaches SPACE_LIMIT, Oracle attempts to reclaim space automatically by deleting files that are obsolete under the RMAN retention policy. Auto-deletion succeeds only if SPACE_RECLAIMABLE is non-zero. If every file in the FRA is still required to satisfy the current retention policy, auto-deletion cannot free anything, and the FRA hits its hard limit.

The cascade from there is fast. Once ARCn cannot write, the archive destination enters an error state. Online redo logs fill. LGWR blocks on log switch. Sessions wait on log file switch (archiving needed). Within minutes, the entire database is frozen.

flowchart TD
    A[FRA fills: archives + backups + flashback logs] --> B[ARCn cannot write archived redo]
    B --> C[Online redo logs cannot be reused]
    C --> D[LGWR blocked on log switch]
    D --> E[All sessions wait: log file switch archiving needed]
    E --> F[Database hangs: instance OPEN, listener UP]
    F --> G[Existing sessions freeze silently]
    F --> H[New non-SYSDBA connections get ORA-00257]

Common causes

Quick checks

These are all read-only and safe to run during an active incident.

-- FRA space: SPACE_LIMIT, SPACE_USED, SPACE_RECLAIMABLE, NUMBER_OF_FILES
SELECT NAME,
       SPACE_LIMIT/1048576       AS limit_mb,
       SPACE_USED/1048576        AS used_mb,
       SPACE_RECLAIMABLE/1048576 AS reclaimable_mb,
       NUMBER_OF_FILES
FROM V$RECOVERY_FILE_DEST;

-- Break down FRA usage by file type
SELECT FILE_TYPE,
       PERCENT_SPACE_USED,
       PERCENT_SPACE_RECLAIMABLE
FROM V$RECOVERY_AREA_USAGE
ORDER BY PERCENT_SPACE_USED DESC;

-- Archive destination status (should be VALID, not ERROR)
SELECT DEST_ID, STATUS, DESTINATION, ERROR
FROM V$ARCHIVE_DEST_STATUS
WHERE STATUS != 'INACTIVE';

-- Archiver process state (should be IDLE or BUSY, not STOPPED)
SELECT PROCESS, STATUS, SEQUENCE#
FROM V$ARCHIVE_PROCESSES;

-- Current dominant wait events
SELECT EVENT, COUNT(*) AS sessions
FROM V$SESSION
WHERE STATUS = 'ACTIVE'
  AND TYPE = 'USER'
  AND WAIT_CLASS != 'Idle'
GROUP BY EVENT
ORDER BY COUNT(*) DESC;

# Alert log tail for archive and FRA errors
adrci exec="show alert -tail 100"

How to diagnose it

1. Confirm the FRA is the bottleneck. Query V$RECOVERY_FILE_DEST. If SPACE_USED is at or near SPACE_LIMIT, the FRA is full. Check V$ARCHIVE_DEST_STATUS: if the FRA is the archive destination (LOG_ARCHIVE_DEST_1 or equivalent is set to USE_DB_RECOVERY_FILE_DEST) and STATUS shows ERROR, the archiver cannot write.

2. Identify what is consuming the space. Query V$RECOVERY_AREA_USAGE. The FILE_TYPE column tells you whether archived logs, backup pieces, flashback logs, or image copies dominate, and that determines your fix path. Archived logs dominating means back them up externally or age them out. Backup pieces dominating points at retention policy or backup frequency. Flashback logs dominating points at DB_FLASHBACK_RETENTION_TARGET.

3. Check whether space is reclaimable. Look at SPACE_RECLAIMABLE in V$RECOVERY_FILE_DEST and PERCENT_SPACE_RECLAIMABLE in V$RECOVERY_AREA_USAGE. Significant SPACE_RECLAIMABLE means Oracle should be able to auto-delete files but has not yet. SPACE_RECLAIMABLE near zero means no files are eligible under the current retention policy and you must intervene manually.

4. Check recent RMAN backup status. If backups have been failing, the FRA accumulates archive logs that RMAN would normally have backed up and aged out. Query V$RMAN_BACKUP_JOB_DETAILS for recent STATUS = 'FAILED' entries. Silent backup failure is the most common root cause of FRA accumulation.

5. Verify the cascade in the alert log. Look for Thread N cannot allocate new log, sequence N, ORA-19809, or ORA-19815. These confirm the FRA hard limit has been reached and the database is hung or about to hang. The log file switch (archiving needed) wait event appearing across many sessions confirms the stall is in progress.

Metrics and signals to monitor

Fixes

The fix path depends on whether SPACE_RECLAIMABLE is non-zero.

If space is reclaimable: run DELETE OBSOLETE

When SPACE_RECLAIMABLE is significant, RMAN has files it considers obsolete under the current retention policy but has not deleted yet. Run:

# Crosscheck first to sync the RMAN catalog with files on disk,
# then delete files no longer required by the retention policy.
rman target / <<EOF
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
DELETE OBSOLETE;
EOF

CROSSCHECK synchronizes the RMAN repository with the filesystem, marking missing files as EXPIRED. DELETE OBSOLETE removes backups and archive logs that exceed the retention policy. This is the preferred fix because it does not require changing configuration or storage allocation. DELETE OBSOLETE prompts for confirmation by default; use DELETE NOPROMPT OBSOLETE in scripted contexts.

If space is not reclaimable: raise DB_RECOVERY_FILE_DEST_SIZE

When SPACE_RECLAIMABLE is near zero and the FRA is full, you must either increase the quota or change the retention policy. To increase the quota immediately:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = <new_larger_value> SCOPE = BOTH;

This is a dynamic parameter change. It takes effect without a restart and persists to the spfile under SCOPE = BOTH. The underlying filesystem or ASM disk group must have the free space to support the new value. Raising DB_RECOVERY_FILE_DEST_SIZE beyond the physical capacity of the destination only delays the stall.

Never delete FRA files with OS commands

Using rm or other filesystem commands to remove files from the FRA does not update the control file. The control file still believes the files exist, leaving SPACE_USED inconsistent with reality and causing RMAN operations to fail. Always use RMAN DELETE commands. If files were already removed manually, run CROSSCHECK to mark them as EXPIRED, then DELETE EXPIRED to clean up the repository.

Adjusting retention policy

If the FRA repeatedly fills because retention requirements conflict with available space, review the policy:

rman target / <<EOF
SHOW RETENTION POLICY;
REPORT OBSOLETE;
EOF

Decide whether REDUNDANCY or RECOVERY WINDOW fits the FRA size. A RECOVERY WINDOW OF 7 DAYS typically requires more space than REDUNDANCY 1 on a system with large daily backups. Retention policy, backup frequency, and FRA size must be sized together.

Prevention

• Monitor the SPACE_USED / SPACE_LIMIT ratio. Alert at 85% (ticket) and 95% (page). This is the single most important FRA metric.
• Track SPACE_RECLAIMABLE alongside SPACE_USED. If SPACE_RECLAIMABLE is zero and SPACE_USED is climbing, auto-deletion cannot help. You are on a fixed clock.
• Verify RMAN backups succeed daily. Check V$RMAN_BACKUP_JOB_DETAILS. Silent backup failures are the most common cause of FRA accumulation because archive logs that RMAN would normally back up and mark reclaimable stay in the FRA indefinitely.
• Size the FRA for the retention policy. If you need 7 days of backups plus flashback logs plus archived redo logs, calculate expected consumption and add headroom.
• Monitor redo generation rate. A sustained increase directly increases archive log consumption. Capacity plan the FRA against peak redo rate, not average.
• On Data Guard standbys, verify reclaimable space reporting. Standby databases may not refresh reclaimable space the same way primaries do (Bug 14227959: standby does not release FRA space while mounted). If SPACE_RECLAIMABLE looks stale, run EXEC DBMS_BACKUP_RESTORE.REFRESHAGEDFILES; on the standby to refresh the reclaimable calculation.

How Netdata helps

• FRA utilization as a continuous signal. Netdata collects V$RECOVERY_FILE_DEST (SPACE_LIMIT, SPACE_USED, SPACE_RECLAIMABLE) per second, so the FRA is visible filling in real time rather than being discovered at 100% during an incident.
• Reclaimable space correlation. When SPACE_USED rises but SPACE_RECLAIMABLE stays near zero, the FRA cannot self-heal. Correlating both signals in one view makes the “no headroom” condition obvious minutes or hours before the archive stall.
• Archive destination status. Netdata surfaces V$ARCHIVE_DEST_STATUS, so a destination transitioning to ERROR appears alongside FRA metrics, confirming the cascade before the alert log fills with cannot allocate new log.
• Redo generation rate trending. Per-second redo size collection shows whether a redo spike is driving archive consumption, distinguishing a workload change from a backup failure.
• RMAN backup status. Job success and failure from V$RMAN_BACKUP_JOB_DETAILS appears alongside FRA metrics, so silent backup failures that cause FRA accumulation are visible before they become an outage.
• Wait event correlation. When log file switch (archiving needed) begins appearing in session waits, Netdata correlates it with FRA fill ratio and archive destination status, narrowing root cause in seconds.

Netdata’s Oracle Database monitoring brings these signals together with per-second metrics and anomaly detection.

Related guides

• ORA-00257: archiver error, connect internal only until freed
• Oracle redo generation rate: capacity planning for archiving and Data Guard
• Oracle redo log switch frequency: undersized logs and checkpoint pressure
• Oracle slow commit cascade: when redo storage degrades and every transaction waits
• Oracle Database monitoring checklist: the signals every production instance needs
• Oracle ‘Checkpoint not complete’: redo log sizing, DBWn, and log-switch stalls