ORA-00257: The Database Stopped Accepting Writes. The Archiver Is Stuck.

The pager goes off at 3 a.m.: the application is frozen. Every screen that tries to save hangs, and the ones that time out come back with ORA-00257: archiver error. Connect internal only, until freed. The database didn’t crash — SELECT still works, you can connect as SYSDBA, the alert log shows no corruption. But nothing can write. The whole business is stopped by a message that reads like a riddle.

Here’s the part that turns the panic into a ten-minute fix: ORA-00257 is not a failure — it’s a refusal. The database is in ARCHIVELOG mode, which means it promises to archive every online redo log before reusing it, so you never lose a committed transaction. The archiver can’t keep that promise right now, so rather than overwrite redo it hasn’t safely copied, it stops accepting new redo altogether. Nine times out of ten the reason is mundane: the place the archived logs go is full. This post is what ORA-00257 actually means, how to confirm the cause in three queries, the fix that clears it without throwing away your recovery window, and a lab that forces the error on demand and then resolves it.

What ORA-00257 actually is

In ARCHIVELOG mode, Oracle writes changes to the online redo logs in a circle — a small, fixed set of groups it fills and reuses. Before it can reuse a group, the archiver process (ARCn) must copy that group to an archive destination — almost always the Fast Recovery Area (FRA), the managed disk area Oracle also uses for backups and flashback logs. That archived copy is what lets RMAN recover the database to any point in time.

ORA-00257 happens when the archiver cannot write the next archived log, so the online logs can’t be recycled, so the database runs out of redo space — and refuses new redo rather than lose it. The message says “connect internal only” (on current releases, Connect AS SYSDBA only until resolved): privileged sessions can still get in to fix it, but everyone else is locked out the instant they try to generate redo.

The critical reframing: ORA-00257 is the symptom the user sees; it is almost never the actual error. The real error is on the archiver side, and it’s usually ORA-19809: limit exceeded for recovery files — the FRA is full. Chase the ORA-00257 and you’ll go in circles; chase the ORA-19809 and you’ll be done in minutes.

Why it happens

The most common cause is the least dramatic one: archived logs piled up and nobody removed them. The FRA has a fixed size (db_recovery_file_dest_size). Every log switch adds an archived log to it. If your backups aren’t also deleting the archived logs they’ve captured — or you have no archive-log backup at all — the FRA fills at exactly the rate the database generates redo. A busy day, a bulk load, an index rebuild, and the area that was “80% full, we’ll deal with it later” tips over.

Then the chain reaction:

• The FRA hits its size limit. ARCn tries to create the next archived log, fails with ORA-19809, and marks the archive destination ERROR. The alert log says, in as many words, Stuck archiver condition declared.
• The online redo logs keep filling with new changes, but none of them can be archived, so none can be reused.
• The moment the database needs to advance into a log it can’t recycle, it stops. Sessions generating redo block; new non-SYSDBA sessions are turned away with ORA-00257.

Other flavors exist — the archive destination points at a filesystem that filled, a directory that lost its permissions, or a Data Guard standby that’s unreachable — but they all reduce to the same thing: the archiver has nowhere to put the next log. The FRA-full case is by far the most common, and the one this lab reproduces.

flowchart TD
A["ARCHIVELOG mode: every online redo log<br/>must be archived before reuse"] --> B["archived logs accumulate<br/>in the fixed-size FRA"]
B --> C{"Are archived logs<br/>backed up and removed?"}
C -->|"yes — RMAN backup + delete"| G["FRA stays healthy,<br/>archiver keeps up"]
C -->|"no — they just pile up"| D["FRA hits its size limit"]
D --> E["ARCn can't write next log → ORA-19809<br/>archive destination = ERROR"]
E --> F["online logs can't be reused →<br/>instance refuses redo → ORA-00257"]
F --> H["Fix: back up + delete archived logs<br/>(and grow the FRA) → archiver resumes"]
H --> G

Confirm the cause in three queries

Don’t guess — the state is fully visible. As SYSDBA:

-- 1. How full is the FRA, and is it the problem?
select space_limit/1024/1024 as limit_mb,
       space_used /1024/1024 as used_mb,
       round(space_used/space_limit*100) as pct
from   v$recovery_file_dest;

-- 2. What is filling it? (almost always ARCHIVED LOG)
select file_type, percent_space_used
from   v$recovery_area_usage
order  by percent_space_used desc;

-- 3. Is the archive destination in error, and why?
select dest_id, status, error
from   v$archive_dest
where  destination is not null;

If query 1 shows ~100% used, query 2 shows ARCHIVED LOG dominating it, and query 3 shows STATUS = ERROR with ORA-19809, you have the FRA-full case — and the alert log will confirm it with Stuck archiver condition declared. That’s your whole diagnosis.

Reproduce it

You don’t have to wait for a 3 a.m. page to see this. Put a database in ARCHIVELOG mode, point archiving at a deliberately tiny 50 MB Fast Recovery Area, and generate a little redo. A couple of log switches fill the FRA; the archiver’s destination fails; then one “application” session floods redo and blocks on a log switch it can’t complete — driving the online logs to full-and-unarchived. Now a normal user tries to connect and work:

round 1: FRA=78%  dest_1=ERROR
>> A normal (non-SYSDBA) user now tries to connect and write...
   ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.

That’s the outage, reproduced deterministically: the archive destination is in ERROR (ORA-19809 under the hood), and every non-SYSDBA session is refused with ORA-00257 — while / as sysdba still connects, exactly as the message promises.

The fix

Two levers, in order. First stop the bleeding, then fix the cause.

Immediate relief — give the archiver room. If you have disk headroom, growing the recovery area unsticks the database in one command, because the archiver retries automatically the moment space appears:

alter system set db_recovery_file_dest_size = 500m scope=both;   -- size to your reality

The real fix — back the archived logs up and remove them. Growing the FRA only delays the next fill; the archived logs are still piling up. Reclaim the space and keep your recovery window by backing the logs up to a location outside the FRA and deleting the inputs, with RMAN:

RMAN> backup archivelog all format '/backup/arch_%U' delete all input;

That copies every archived log to /backup, deletes the FRA copies it just secured, and frees the space — so you can still recover, and the FRA drains. Once there’s room, the destination returns to VALID and writes resume:

FRA now 14% full, dest_1 = VALID
ARC_OK ROWS=450002

Same database, same user that was locked out a moment ago — now connecting and writing.

Don’t take my word for it — run it. The archiver-stuck lab puts Oracle Database Free in ARCHIVELOG mode with a 50 MB FRA, fills it until the archive destination goes to ERROR (ORA-19809), and asserts that a normal user is refused with ORA-00257 while SYSDBA still connects. Then it runs the RMAN backup-and-delete plus a size bump and asserts the destination returns to VALID and the same user writes again. If the outage doesn’t reproduce — or survives the fix — the run fails. Proven on every CI push.

The point isn’t the emergency; it’s that you should never have to run it. Once you’re back up: schedule the archive-log backup (BACKUP ARCHIVELOG ALL DELETE INPUT on a cadence that keeps ahead of your redo rate), size the FRA for real workload plus a safety margin, and monitor V$RECOVERY_FILE_DEST percent-used with an alert well below 100% — 85% is a good line. The whole outage is a monitoring gap wearing an error number.

What teams get wrong

• rm on the archived logs. Deleting archived logs at the OS level frees space and silently breaks your backups: RMAN still thinks those logs exist, its recovery catalog is now wrong, and your next restore fails at the worst possible time. Always delete through RMAN (DELETE ARCHIVELOG, or DELETE ... INPUT on a backup), or at minimum CROSSCHECK ARCHIVELOG ALL afterward so RMAN knows what’s really there.
• Deleting without backing up. Freeing the FRA by deleting archived logs you never captured unsticks the database and destroys your ability to recover to any point after your last full backup. Back up first, then delete — that’s what DELETE INPUT does in one step.
• Turning off ARCHIVELOG mode to make it stop. NOARCHIVELOG makes ORA-00257 impossible because it makes point-in-time recovery impossible. That’s not a fix; it’s trading an outage for the inability to recover from the next one. Keep archiving on and fix the space.
• Sizing the FRA once and forgetting it. Redo volume grows with the workload. An FRA that held three days of logs last year holds eight hours during this year’s migration. Size it against current redo generation, not the day you built the database.
• No monitoring. ORA-00257 almost never arrives without warning — the FRA climbs through 80%, 90%, 95% over hours or days. A single alert on V$RECOVERY_FILE_DEST percent-used turns a 3 a.m. outage into a ticket you handle at 4 p.m.
• Assuming it’s always the FRA. Usually it is, but check V$ARCHIVE_DEST.ERROR — a full non-FRA archive filesystem, a permissions change, or an unreachable Data Guard destination produces the same ORA-00257 with a different root error. Fix the destination the error actually names.

Archiver-stuck belongs to the same reliability story as the rest of Oracle’s recovery machinery: the archived logs whose accumulation caused this outage are exactly what RMAN needs to recover the database to a point in time, which is why you delete them through RMAN and never with rm; ARCHIVELOG mode is also what makes Flashback Database and guaranteed restore points possible; and it is a different failure from the undo-side ORA-01555 snapshot too old, which people confuse with it because both involve a long-suffering database and a cryptic number. ORA-00257 is the archiver protecting your recovery guarantees — read the real error (ORA-19809, a full FRA), free the space the right way, put a monitor on the recovery area, and then prove the whole cycle with the archiver-stuck lab, where a full FRA locks out every non-SYSDBA session and an RMAN backup-and-delete brings it straight back.