Archive Process Options

Selecting an archive destination (where archived redo will be written) is only one piece of the archiving story. In Oracle 23ai, “archive process options” really means understanding: (1) when archiving is possible, (2) how Oracle behaves under pressure (redo generation vs. archiving throughput), and (3) how archived redo fits into backups, recovery, and standby/HA designs.

Critical prerequisites and operational realities

1. ARCHIVELOG mode is required. Archiving of filled online redo log groups into archived redo log files only occurs when the database is running in ARCHIVELOG mode. In NOARCHIVELOG mode, redo log groups are reused (overwritten) after log switches.
2. Switching modes requires a consistent transition. To enable ARCHIVELOG, shut down cleanly and start the database in MOUNT state. You cannot toggle the mode while the database is fully open for transactions.
3. Backpressure is real: archiving can stall the database. In ARCHIVELOG mode, LGWR cannot reuse a redo log group until it has been archived. If the archive destinations are full or the archiver falls behind, the database can appear to “hang” while waiting for space or for archiving to complete. This is expected protective behavior—not a random crash.
4. Archiving must keep up with workload. Your I/O, destination design, and retention strategy must support peak redo generation. If archiving lags, you can see performance degradation (waits on log switches, checkpoint pressure, or stalled reuse).
5. Archived redo supports standby and recovery workflows. Archived logs are central to media recovery and commonly used in standby designs (Data Guard) where redo is shipped and applied to maintain a synchronized copy at a remote site.

Archived redo logs are files produced from the online redo logs. When a redo log group fills, Oracle performs a log switch and begins writing to the next available online redo log group. In ARCHIVELOG mode, Oracle’s archiver processes (ARCn) copy the full redo log group into an archived log file.

Where those archived log files land depends on your configuration (FRA, filesystem paths, multiple destinations). Older training material often references fixed default paths, but modern Oracle environments are typically configured via the FRA and/or LOG_ARCHIVE_DEST_n.

$ORACLE_HOME/dbs/arch

Each archived log corresponds to redo content that can be applied during recovery to roll datafiles forward from a backup to a later point in time.

Imagine you took a full backup on Monday. On Tuesday, a datafile is lost due to media failure. You restore the missing datafile from Monday’s backup. At that moment, the restored file is not current—its SCN lags behind the rest of the database.

Oracle uses archived redo logs to roll the restored datafile forward by applying the changes that occurred after the backup was taken. The recovery process continues in sequence; if an archived log required for recovery is missing, recovery stops at that gap.

This is why production recovery strategy is always described as backup + archived redo (and sometimes additional redo shipped to a standby). Without archived redo, you can restore only to the point-in-time of the backup and you lose all subsequent changes.

The exact commands are simple, but it’s important to remember the required database state: the database must be mounted (not open). The legacy LOG_ARCHIVE_START parameter is not the modern control mechanism; in current releases, archiving behavior is managed through ARCHIVELOG mode plus archive destination configuration.

sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

After enabling ARCHIVELOG mode, configure archive destinations appropriately (for example, FRA settings and/or LOG_ARCHIVE_DEST_n). You can confirm mode with:

SELECT log_mode FROM v$database;
-- or in SQL*Plus/SQLcl:
ARCHIVE LOG LIST;

The guiding principle is straightforward:

You keep archived redo logs as long as they are needed to recover from the backups you still retain.

If you rotate backups (for example, keeping one week of recoverable backups), then your archived redo retention must cover that same window—otherwise your backups may not be recoverable beyond the time of the backup itself.

Archived redo logs have no recovery value if the corresponding backup is gone. Conversely, a backup without the archived redo required to roll forward provides only limited recovery: you can restore to the backup timestamp, but you cannot recover past it.

Recovery also cannot “skip” missing logs. Oracle applies archived redo in sequence; when it encounters a missing required log, recovery halts at that point.

Now that we have a foundation for how Oracle preserves change data (redo) and how that change data is archived, the next lesson focuses on normal ARCn processing and the practical monitoring signals that tell you archiving is healthy.