ORA-00257 archiver error: the database is hung, here's how to recover

#Symptoms

• New connections fail with ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.
• Existing sessions hang on commit.
• The alert log shows ORA-19815: WARNING: db_recovery_file_dest_size of ... bytes is 100.00% used.

#1. Confirm where the space ran out

sqlplus / as sysdba

SELECT name, space_limit/1024/1024/1024 AS limit_gb, space_used/1024/1024/1024 AS used_gb,
       space_reclaimable/1024/1024/1024 AS reclaimable_gb, number_of_files
FROM v$recovery_file_dest;

SELECT file_type, percent_space_used, percent_space_reclaimable FROM v$recovery_area_usage;

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

#2. Quickest safe relief: raise the FRA limit (if the disk has room)

ALTER SYSTEM SET db_recovery_file_dest_size = 400G SCOPE = BOTH;

The archiver resumes within seconds. This only works if the filesystem or ASM disk group actually has free space.

#3. Free space with RMAN (the proper way)

Back up the archive logs first, then delete them:

rman target /

BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES DELETE INPUT;

If you're certain they're already backed up:

CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK COMPLETED BEFORE 'SYSDATE-1';

Also check obsolete backups and old flashback logs:

REPORT OBSOLETE;
DELETE NOPROMPT OBSOLETE;

Warning

Never delete archive logs with rm at the OS level. RMAN won't know they're gone, and you may delete logs a standby still needs (Data Guard), breaking recovery. If you did, run CROSSCHECK ARCHIVELOG ALL immediately.

#4. Verify

ALTER SYSTEM ARCHIVE LOG CURRENT;
SELECT sequence#, archived, status FROM v$log;

#5. Data Guard

If the logs pile up because a standby isn't receiving them, deletion policy APPLIED ON ALL STANDBY keeps them. Fix the standby (network, v$archive_dest error) instead of deleting logs.

#Prevent it

• Archive log backups with DELETE INPUT every 1–4 hours, not only nightly.
• Alert on FRA usage at 75% and 90% (v$recovery_file_dest, or Enterprise Manager / OCI Database Management metric).
• Size the FRA for at least two days of archive generation:

SELECT TRUNC(completion_time) day, ROUND(SUM(blocks*block_size)/1024/1024/1024,1) gb
FROM v$archived_log GROUP BY TRUNC(completion_time) ORDER BY 1 DESC FETCH FIRST 14 ROWS ONLY;

Tip

A sudden jump in daily archive volume usually means a new batch job or a missing NOLOGGING-safe design. Ask what changed before just adding disk.