Scops
Docs Download

Oracle problems

Archiver Stuck: ORA-16014, Which Destination Failed, and the Fix

3 November 2026

An archiver that cannot write stops the database, slowly: the archiver processes retry the failed destination, the online redo logs fill up unarchived, the log writer reaches one it cannot reuse, and every session waits on log file switch (archiving needed) until the alert log is full of ORA-16014, a log that could not be archived because no destination was available, or ORA-16038, a log that cannot be archived at all. The cause is one destination: a full disk, a path that is gone, a recovery area at its quota, or a standby that cannot be reached. V$ARCHIVE_DEST names it, with Oracle's own error text, and the fix is to free or repair that destination and tell the archiver to try again.

Which destination, and what it said

SELECT dest_id, dest_name, status, binding, target, destination,
       error, fail_date, failure_count, max_failure, reopen_secs,
       alternate, log_sequence
FROM   v$archive_dest
WHERE  status <> 'INACTIVE'
ORDER  BY dest_id;

Oracle's reference lists the states of STATUS: VALID, initialized and available; DEFERRED, manually disabled by the user; ERROR, error during open or copy; DISABLED, disabled after error; BAD PARAM, parameter has errors; ALTERNATE, destination is available as an alternate; FULL, exceeded quota size for the destination. ERROR displays the error text, FAIL_DATE the date and time of the last error, and FAILURE_COUNT the current number of contiguous archival operation failures for the destination. BINDING says whether a failure stops the database: MANDATORY, successful archival is required; OPTIONAL, successful archival is not required, subject to LOG_ARCHIVE_MIN_SUCCEED_DEST. The standby side of the same picture:

SELECT dest_id, status, type, database_mode, recovery_mode,
       archived_seq#, applied_seq#, gap_status, error
FROM   v$archive_dest_status
WHERE  status <> 'INACTIVE'
ORDER  BY dest_id;

The archivers, and the logs they owe

SELECT process, status, state, log_sequence
FROM   v$archive_processes
WHERE  status <> 'STOPPED';

STATE is IDLE or BUSY, and LOG_SEQUENCE the online redo log sequence number being archived when busy. Every archiver busy on the same sequence for minutes is the stuck one. The logs waiting their turn:

SELECT group#, thread#, sequence#, status, archived, first_time
FROM   v$log
ORDER  BY thread#, sequence#;

A group with ARCHIVED at NO that is not CURRENT is a log the archiver has not written yet; when every group but the current one is in that state, the next switch is the stop. The sessions already waiting are in V$SESSION on log file switch (archiving needed), and Oracle's reference says of that wait: check the alert log to ensure that archiving has not stopped due to a failed archive write.

The fix, in order

  1. Read the error, and fix that. The ERROR column has the exact reason: a file system with no space, a path that is not mounted or not writable, a recovery area at its quota, or a Net error for a standby that cannot be reached. Free the space, mount the path, raise DB_RECOVERY_FILE_DEST_SIZE, or let the backup that deletes archived logs run; nothing else helps until this is done.
  2. Tell the archiver to try again. ALTER SYSTEM SET log_archive_dest_state_2 = 'RESET', which Oracle's reference says functions the same as DEFER but clears any error messages for the destination if it had previously failed, then 'ENABLE'; and ALTER SYSTEM ARCHIVE LOG ALL writes every log that is waiting. The sessions on the switch wait are released at the first archived log.
  3. Defer a destination that will stay broken. LOG_ARCHIVE_DEST_STATE_n = 'DEFER' keeps the destination's attributes and excludes it from archiving until re-enabled, so a standby host that is down for the weekend does not hold the primary. The local destination keeps archiving, and the standby resolves its gap when it is back.
  4. Mark a destination MANDATORY only on purpose. Oracle's reference: a mandatory destination's transmission must succeed before the local online redo log file can be made available for reuse, and destinations are optional by default, with LOG_ARCHIVE_MIN_SUCCEED_DEST at 1 defining the minimum number of destinations that must succeed. A remote destination marked mandatory makes the primary's uptime depend on the standby's network.
  5. Give the archiver somewhere else to go. The ALTERNATE attribute names a destination to use when the original fails; Oracle's reference says that without one archiving does not automatically change to another destination if the original destination fails. A second local destination on other storage, in the ALTERNATE state, turns a full disk into a note in the alert log.
  6. Enough archivers, and a retry that fits. LOG_ARCHIVE_MAX_PROCESSES defaults to 4 and goes to 30; raise it when the logs switch faster than the archivers write. REOPEN, 300 seconds by default, is how long the archiver waits before retrying a failed destination, and MAX_FAILURE how many consecutive failures it allows before the primary gives up on the destination.

See it coming

Radar Engine, the detection layer of Scops, reads the archive destinations of every database, watches the sessions on the archiving switch wait live, and reads the alert log for the archiver's own messages, so a destination in error is a finding before the online logs fill, with the destination and Oracle's error text in it:

DetectorClockWhen it fires
Archive destination failingA local archive destination in error.Warning.
Redo log switches wait for archivingLive. log file switch (archiving needed).From 0.3 active sessions: Warning. From 1, still rising: Critical.
Logs: a stuck archiverSerious errors in the alert log, such as a stuck archiver.A serious error for the first time in 24 hours: Critical.

The recovery area has its own forecast, in the ORA-00257 guide. Scops reads all of it through a read-only account, with nothing installed on the server and no Diagnostics Pack, on Standard Edition 2 as on Enterprise Edition.

Questions

What does ORA-16014 mean?
A redo log could not be archived because no archive destination was available to take it: every enabled destination was in error, full or deferred. V$ARCHIVE_DEST shows which one failed and Oracle's error text for it.

What is the difference between ORA-16014, ORA-16038 and ORA-00257?
ORA-16014 is no available destination; ORA-16038 is a log that cannot be archived, with the underlying error alongside it in the alert log; ORA-00257 is the archiver error a user sees at connect time when the recovery area or destination is full. All three end the same way: free or repair the destination and archive the waiting logs.

How do I restart archiving after the destination is fixed?
Set LOG_ARCHIVE_DEST_STATE_n to RESET, which clears the error, then to ENABLE, and run ALTER SYSTEM ARCHIVE LOG ALL to write the logs that are waiting. The sessions on log file switch (archiving needed) continue as soon as a log is reusable.

Should a standby destination be MANDATORY?
Rarely. A mandatory destination must succeed before an online log can be reused, so a standby that cannot be reached stops the primary. Oracle's default is optional, with one successful destination required; protection modes are the place to decide how much the primary waits for a standby.

Related problems

Sources