Lesson 1

In Oracle Database, every change is first recorded in the online redo logs. When the database is running in ARCHIVELOG mode, those filled redo logs are copied to archived redo logs so they can be used for recovery and high-availability features. This module introduces the two ways DBAs think about archiving: automatic archiving (the normal modern behavior in ARCHIVELOG mode) and manual archiving (a legacy operational concept that survives today mostly as “manual forced archive actions”).

By the end of this module you should be familiar with:

1. Normal ARCn (archiver) processing in ARCHIVELOG mode
2. How and when a DBA can manually force an archive
3. How automatic archiving is configured using archive destinations
4. How to retrieve archive log information for monitoring and troubleshooting

The module also includes a short discussion of standby databases. Standby databases remain a practical HA/DR option because they can reduce downtime and revenue loss compared to a full restore-and-recover event on a single primary database.

The next lesson discusses archiving your redo log files.

In Oracle 23ai, the “manual vs automatic” distinction has evolved:

• Automatic archiving (normal behavior): When the database is in ARCHIVELOG mode and archive destinations are valid, Oracle’s ARCn background processes automatically copy filled online redo logs to one or more archive destinations (for example, the FRA or a filesystem path defined by LOG_ARCHIVE_DEST_n).
• Manual archiving (modern meaning): DBAs can still manually trigger archiving actions when needed—most commonly to force the current redo log to be archived (useful before maintenance steps, backups, or certain recovery workflows).
• Privileges and state requirements: Switching the database into ARCHIVELOG mode requires SYSDBA/SYSOPER privileges and is performed with the database mounted (not open). Day-to-day monitoring queries and forced archive commands typically require elevated privileges.

This module focuses on redo log archiving. Keep in mind that Oracle also has other features that use the word “archive” (for example, application-level “in-database archiving” patterns, or information lifecycle policies). Those are conceptually different from archived redo logs used for media recovery.

Even when archiving is “automatic,” DBAs often need to force specific redo/archiving events:

• Force the current redo log to be archived (archives the current log and performs a log switch):

  ALTER SYSTEM ARCHIVE LOG CURRENT;

• Force a log switch (often used during testing/monitoring; archiving follows if in ARCHIVELOG mode):

  ALTER SYSTEM SWITCH LOGFILE;

These commands do not “replace” automatic archiving. They are DBA-controlled triggers that can help you validate configuration, advance redo sequences, or ensure a known recovery point.

Automatic archiving in Oracle is largely a combination of:

1. ARCHIVELOG mode (database-wide state)
2. Archive destinations (where archived logs will be written)
3. ARCn processes (the background processes that perform the copies)

Typical configuration points include the Fast Recovery Area (FRA) via DB_RECOVERY_FILE_DEST and one or more destination parameters like LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, etc.

In a healthy configuration, ARCn copies redo logs as they fill. If archiving stops unexpectedly, the most common root cause is a destination problem (full FRA/filesystem, permission issues, invalid path, or transport errors in a Data Guard configuration).

A quick check for the archiver status is the ARCHIVER column in V$INSTANCE:

SELECT archiver
FROM   v$instance;

Typical output

ARCHIVER
--------
STARTED

A value of STARTED indicates that archiving is enabled and Oracle’s archiver processes are running. If the value is STOPPED, the database is either not archiving redo (for example, in NOARCHIVELOG mode) or archiving is not currently active due to configuration/state.