Archived Redo Log Files in Oracle AI Database 26ai

Online redo and archived redo serve different stages

LGWR writes the current online redo group for its thread. When writing moves to another group, the completed sequence can be archived. The source group remains an online group; archiving creates a separate file rather than converting the original file into an archive.

An archive is not another group waiting for LGWR to select it. Its contents belong to a particular redo sequence. Removing an archive after its retention requirements are satisfied is different from overwriting an online group during normal operation.

For a multiplexed group, ARCn can obtain the redo from one usable member. It does not join the members together or require a separate archive for each member. If one member is corrupt, an intact partner can supply the same redo. Oracle describes this relationship in Managing Archived Redo Log Files.

Follow a sequence through archiving and reuse

Suppose group 1 is current and LGWR is writing sequence 120. At a log switch, LGWR begins the next sequence in another reusable group. ARCn can then archive sequence 120 from group 1 while database activity continues.

A switch usually occurs when the current group fills, but it can also be requested before that point. Group 1 keeps its group number when it is used again, while its new contents receive another sequence number. Group numbers describe the configuration; sequence numbers identify successive portions of the redo stream.

In a simple three-group cycle, groups 1, 2, and 3 might hold sequences 120, 121, and 122. When group 1 is reused for sequence 123, its old sequence 120 survives in an archive. Adding another member to group 1 would create redundancy for that group's current contents; it would not preserve every earlier sequence automatically.

Before a previously used group is reusable, checkpoint progress must make its redo unnecessary for instance recovery. In ARCHIVELOG mode, the required archiving must also have succeeded. These conditions can finish in either order: an archived group can still be needed for instance recovery, and an inactive group can still be awaiting archiving.

A log switch therefore does not prove that the previous group is immediately reusable. The distinction is important when investigating waits. Additional groups may provide more time before reuse, but they cannot repair a failed archive destination. See Oracle's explanation of online redo switches.

ARCHIVELOG and NOARCHIVELOG: the recovery difference

Online backups still depend on the required redo

ARCHIVELOG allows a backup strategy that keeps the database open while RMAN backs up its files. Because an open database changes during the backup, recovery uses redo to make the restored files consistent and advance them to the intended state.

This does not mean that any operating-system copy of open database files is a valid backup. Use supported backup procedures and preserve the redo needed by them. With NOARCHIVELOG, RMAN database backups must be consistent, normally taken with the database mounted after a clean shutdown.

Plan datafile and archive backups together. A recent datafile backup is less useful if its required archives are missing, and a directory full of archives is not a replacement for the starting datafiles. See RMAN Backup Concepts.

Verify the plan with a recovery exercise in an appropriate separate environment. Reading a backup job's successful completion message answers a narrower question than demonstrating that the required files can be restored and recovered together. Record the tested recovery point and elapsed time so the result can be compared with the application's requirements.

Choose and understand archive destinations

The modern parameter family is LOG_ARCHIVE_DEST_n. It supports numbered destinations 1 through 31, with an important restriction: destinations 1 through 10 can be local or remote, while 11 through 31 are remote-only. The range does not provide 31 local archive directories.

Actual paths, disk groups, and service names depend on the installation. The older LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST pair remains documented, but numbered destinations provide the basis for this lesson's explanation.

Destination requirements also affect reuse. Mandatory destinations must succeed, and LOG_ARCHIVE_MIN_SUCCEED_DEST sets the minimum required number of successful destinations. Neither “every destination must always succeed” nor “one copy always suffices” describes every configuration. Consult LOG_ARCHIVE_MIN_SUCCEED_DEST when interpreting those requirements.

Data Guard adds remote transport: redo can be sent while it is generated and applied from standby redo logs before those logs are archived. An actively written standby redo log is distinct from an archived file. A SERVICE destination therefore does not simply mean another local archive directory. See Data Guard Apply Services.

Identify archives by thread, sequence, and incarnation

For user-managed archive naming, a format such as arch_%t_%s_%r.arc includes the redo thread, sequence number, and RESETLOGS identifier. The sequence orders redo within a thread; the RESETLOGS identifier distinguishes database incarnations whose sequence numbers could otherwise overlap.

When setting LOG_ARCHIVE_FORMAT, include all three elements. Oracle ignores this parameter for FRA archives and destinations pointing to an ASM disk-group root, where Oracle-managed names apply. Do not assume that every ASM directory behaves identically. See the LOG_ARCHIVE_FORMAT reference.

Use database records to identify a log instead of relying only on its filename. This becomes especially important when there are multiple copies of one sequence or archives from more than one thread.

Manage the fast recovery area and archive retention

The fast recovery area, or FRA, is managed disk storage for recovery files. DB_RECOVERY_FILE_DEST specifies its location, and DB_RECOVERY_FILE_DEST_SIZE specifies the database's quota. Archives share this capacity with other recovery files, including backups and flashback logs.

A configured FRA can become the local archive destination when no local destination is explicitly specified. Check the actual configuration rather than assuming that every installation has an FRA. Its name also says nothing about storage independence or whether its contents have been copied off site.

RMAN's backup retention policy identifies backups required for the recovery goal. The archived-log deletion policy governs when archives are eligible for deletion. These related policies are not a single fixed number of days that every installation must retain each local archive.

Within the FRA, Oracle can reclaim eligible files when space is needed. Outside the FRA, setting an archive directory does not provide automatic cleanup. Account for downstream consumers, including standby databases, before deciding when archives can be removed. See Configuring the RMAN Environment.

Archive backup and archive deletion are separate actions. RMAN can back up archives to disk or through the appropriate media-management integration for tape or supported cloud storage. ARCn's local archiving role should not be confused with writing directly to a tape drive.

Operational costs include archive write I/O, backup throughput, and monitoring as well as capacity. If required archiving cannot finish, online groups can eventually become unavailable for reuse and database work can stall. More online groups may postpone that point without solving the underlying storage or destination error.

For a rough capacity example, retaining three days of archives at 40 GiB per day requires about 120 GiB for those archive files at one destination. Allow additional capacity for workload peaks and other files. Two complete archive destinations each need their own allocation. This estimate is a planning illustration, not a recommended retention period or an FRA sizing formula.

Measure representative activity, including batch loads and busy business periods. A quiet day's redo volume can underestimate both storage demand and the throughput needed to archive and back up logs during a peak. Also consider how long archives may accumulate if the backup destination becomes temporarily unavailable.

Check archive operation with read-only queries

Use a DBA-authorized connection with access to the required dynamic performance views. For CDB-wide administration, use the CDB root context. PDBs do not each have their own independent online redo groups or ARCHIVELOG setting. These queries are examples, not captured output from a particular database.

1. Check the database mode

SELECT name, log_mode
FROM v$database;

Confirm the database identity before interpreting the mode. ARCHIVELOG shows that archiving is enabled; it does not certify that today's destinations are healthy or that a usable backup exists.

2. Inspect archive destinations

SELECT dest_id, destination, status, binding, error
FROM v$archive_dest
WHERE status <> 'INACTIVE'
ORDER BY dest_id;

The filter excludes entries with no destination information. It still includes destinations that are deferred, disabled, in error, or configured as alternates. Read the error text and binding with the status rather than treating all returned rows as working destinations.

This view describes the current instance. In RAC, one instance's result does not audit the entire cluster. The V$ARCHIVE_DEST reference explains the individual status values.

3. Inspect recent archive records

SELECT thread#, sequence#, resetlogs_id, dest_id,
       name, completion_time, status, deleted
FROM v$archived_log
ORDER BY completion_time DESC NULLS LAST, recid DESC
FETCH FIRST 50 ROWS ONLY;

This sample shows recent records, not a complete recovery inventory. Multiple destinations, restored archives, or additional copies can produce several rows for one sequence. COMPLETION_TIME records archive completion; FIRST_TIME and NEXT_TIME describe redo boundaries.

For example, two rows with sequence 120 can represent copies at two destinations. They do not indicate that two different portions of history share the same sequence accidentally. Conversely, a sequence absent from this 50-row sample might exist outside the sample or in backup. Investigate the required thread and incarnation before declaring a recovery gap.

Status A means available, D deleted, U unavailable, and X expired. A record or DELETED value of NO does not prove that the file is currently readable. A null NAME can reflect a cleared log or an RMAN backup using DELETE INPUT, so it has more than one interpretation. Consult V$ARCHIVED_LOG when investigating an entry.

4. Check FRA capacity

SELECT name,
       ROUND(space_limit / POWER(1024, 3), 2) AS quota_gib,
       ROUND(space_used / POWER(1024, 3), 2) AS used_gib,
       ROUND(space_reclaimable / POWER(1024, 3), 2) AS reclaimable_gib,
       number_of_files
FROM v$recovery_file_dest;

The query reports binary gibibytes. The quota is the database's FRA allowance, not the underlying filesystem's free space. Reclaimable bytes are still occupied until reclaimed. Check the actual filesystem or ASM capacity as well as these database figures.

Absent FRA configuration does not mean that archiving is disabled; archives might use another destination. Compare the results with destination status and alert-log messages. See V$RECOVERY_FILE_DEST.

Connect archiving to checkpoints

Archived redo preserves changes after online groups are reused. Checkpoints address how far those changes have reached the datafiles and how much redo instance recovery may still need. Keeping those responsibilities separate explains why both checkpoint progress and successful archiving can affect group reuse.

The next lesson examines the Oracle checkpoint process and its role in recovery.