Configure Multiple Archive Log Destinations in Oracle 26ai

Distinguish online redo members from archive copies

Online redo records database changes as they occur. LGWR writes redo to the members of the current online redo log group. Multiple members in a group protect that group's contents against certain member failures. In ARCHIVELOG mode, completed redo is archived so it remains available after online groups are reused. Archiver processes are commonly identified as ARCn.

Adding another online member does not create another archive destination. Likewise, adding an archive location does not add a member to an online group. Review both layers when designing recovery protection. The following query identifies online and standby redo members; use its TYPE column to distinguish them:

SELECT group#, type, member, status
FROM v$logfile
ORDER BY group#, member;

As a separate online-redo example, a DBA could add a member to an existing group 1:

ALTER DATABASE ADD LOGFILE MEMBER
  '/u04/oradata/redo01b.log' TO GROUP 1;

This assumes a reviewed group layout, an unused filename, appropriate privileges, and accessible storage. It creates a member of that group, not a new group. A newly added member may initially show INVALID until first use; interpret status in context and verify subsequent use. Do not add members merely to complete the archive-destination exercise below.

Understand the destination parameters

LOG_ARCHIVE_DEST_n identifies a numbered destination. The suffix is its destination identifier, sometimes called its handle^[1]. Oracle 26ai provides slots 1 through 31, with important restrictions: slots 11 through 31 do not support LOCATION, MANDATORY, SYNC, ARCH, or ALTERNATE. Use slots 1 through 10 for local destinations. These are not 31 interchangeable local folders.

A destination is optional by default when MANDATORY is omitted. The explicit OPTIONAL attribute is deprecated, so the new examples omit it. Destination 1 is not inherently mandatory, and numbering alone does not establish a primary/secondary priority policy. Read the actual attributes and state.

Prepare a controlled configuration change

The lab assumes a self-managed, single-instance primary database already running in ARCHIVELOG mode, an SPFILE, and an authorized DBA connected to CDB$ROOT. The destination parameter is not modifiable within a PDB. RAC, Data Guard broker, and managed database services need procedures appropriate to their management model; do not apply this single-instance example unchanged.

In SQL*Plus, inspect the context and existing settings before assigning destination slots:

SHOW CON_NAME
ARCHIVE LOG LIST
SHOW PARAMETER spfile
SHOW PARAMETER log_archive_dest
SHOW PARAMETER log_archive_min_succeed_dest
SHOW PARAMETER db_recovery_file_dest

SELECT name, database_role, log_mode
FROM v$database;

Record the complete destination strings, destination states, and required-success setting. The SHOW PARAMETER log_archive_dest search includes related destination names and states; review all populated entries. Preserve persistent settings as well as current values if they differ. These records form the rollback plan. A command that replaces a destination string also replaces attributes previously contained in that string.

Reserve destinations 1 and 2 specifically for this lab. If either already supports production archiving or a standby, stop and choose a reviewed configuration instead of overwriting it. Confirm edition support and the privileges needed for ALTER SYSTEM. An application account and a password copied from an old tutorial are not appropriate preparation for an instance-wide change.

Have the storage administrator prepare /u02/arch_a and /u03/arch_b on independent storage, with enough capacity and access for the Oracle database service. SQL destination settings do not create directories or correct filesystem permissions. On Windows, use suitable server-side Windows paths. Different drive letters or mount names alone do not prove that two paths have independent failure risks.

Configure two local archive destinations

For the prepared lab, set both locations and enable both destinations:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=
  'LOCATION=/u02/arch_a' SCOPE=BOTH;

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
  'LOCATION=/u03/arch_b' SCOPE=BOTH;

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

SCOPE=BOTH applies the change to memory and the SPFILE. It assumes the instance uses an SPFILE. A PFILE-based environment needs a separate persistence procedure. After each change, inspect the result and retain any error output. Successful parameter assignment establishes configuration; it does not prove that Oracle has written an archive file to both paths.

The example deliberately leaves both destinations optional. Before proceeding, confirm that the lab's existing LOG_ARCHIVE_MIN_SUCCEED_DEST value is 1 and that no other configured destinations change the intended behavior. If the existing policy differs, reconcile that policy explicitly rather than lowering it to fit the example. Both configured locations are intended to receive redo, even when the reuse requirement is only one successful copy.

Choose whether one or both copies must succeed

With exactly two optional local destinations and a minimum of 1, one successful eligible destination is sufficient for log reuse. Failure of the other still represents degraded protection and needs attention. With a minimum of 2, both must succeed. Once both locations have been verified, the lab can demonstrate that stronger requirement:

ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST=2 SCOPE=BOTH;

This is a protection-versus-availability decision. Requiring two copies prevents reuse until the required archival succeeds, but an unavailable destination can eventually stop progress when reusable online groups run out. It does not necessarily stop a transaction at the instant one archive write fails. Explain this consequence to the service owner before adopting the policy.

Mandatory attributes add another constraint. Every enabled, valid mandatory destination must succeed even if the numeric minimum is lower than the mandatory count. Optional remote destinations do not count like optional local destinations toward this minimum. Evaluate the actual configuration rather than counting parameter names. A destination state, its attributes, and the required-success value jointly determine the policy.

Verify matching archived redo at both locations

In the prepared lab, request archival of the current redo and then inspect the destinations:

ALTER SYSTEM ARCHIVE LOG CURRENT;

SELECT dest_id, status, binding, destination, error
FROM v$archive_dest
WHERE dest_id IN (1, 2)
ORDER BY dest_id;

Investigate errors before declaring success. A configured destination should be enabled and usable, with no unexplained destination error. V$ARCHIVE_DEST reports configuration and status for the current instance. A RAC verification procedure must account for each relevant instance and redo thread rather than assuming one instance's output covers the cluster.

Examine recent archived-log records and compare copies of the same redo:

SELECT resetlogs_change#, thread#, sequence#,
       dest_id, name, completion_time
FROM v$archived_log
WHERE dest_id IN (1, 2)
  AND completion_time > SYSDATE - 1/24
  AND name IS NOT NULL
ORDER BY resetlogs_change#, thread#, sequence#, dest_id;

The time filter selects the previous hour for convenient inspection. Adjust it for the exercise, and identify the specific sequence created during the test. Match RESETLOGS_CHANGE#, THREAD#, and SEQUENCE#, then look for the intended destination IDs and distinct file paths. Two rows with different sequence numbers do not prove that both destinations contain a copy of the same redo.

Archived-log history can contain multiple records for other reasons, including restore or copy operations. A control-file entry also does not prove a file still exists. Check the named files through the approved storage tools, retain the query output, and connect this test to the organization's recovery-validation procedure. These are expected checks, not sample results from a database execution.

Use the Fast Recovery Area deliberately

The FRA provides Oracle-managed space for recovery files. Its location and quota are controlled by DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. RMAN can be used without an FRA, but a correctly sized FRA can simplify recovery-file management. It does not eliminate capacity planning or the need for copies outside a shared failure domain.

If an FRA already exists and destination 1 is deliberately allocated to it, the following is an alternative to the first local path in the earlier example:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=
  'LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH;

This replaces destination 1's value; it is not an extra third destination. Preserve any required attributes when adapting it. Inspect effective settings instead of assuming that an implicit LOG_ARCHIVE_DEST_10 always provides the desired archive copy. Verify where the FRA actually resides before deciding that a second directory protects against its loss.

Monitor the recovery-area quota, usage, and reclaimable space:

SELECT name, space_limit, space_used,
       space_reclaimable, number_of_files
FROM v$recovery_file_dest;

The space columns are in bytes. Compare this database view with actual filesystem or ASM capacity. A large logical quota cannot create physical free space. Retention, backup status, and standby requirements affect which files may be removed. Use the established RMAN-aware maintenance procedure rather than deleting archive files from the operating system simply because a directory appears full.

Recognize the role of a remote standby

A local second archive path can help with a storage failure while leaving both copies exposed to a host or site failure. A separately located standby can provide a different protection boundary. A SERVICE destination identifies a prepared remote database for redo transport, but setting a service string alone does not build a Data Guard configuration.

A complete standby design includes authentication, network connectivity, database identity, standby redo handling, transport settings, apply, and monitoring. Receiving redo and applying redo are separate activities. Check both transport and apply health, and evaluate lag against the recovery objective. Asynchronous transport should not be described as an unconditional zero-data-loss guarantee.

Choose the number and placement of destinations from concrete failure scenarios. There is no universal rule that two destinations are insufficient or that five destinations provide no benefit. Each additional copy should have a purpose, capacity plan, owner, and verification method. Copies that are rarely checked can create confidence without dependable recovery capability.

Handle legacy duplex parameters carefully

LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST describe the older two-destination approach. Oracle's 26ai reference retains them for applicable configurations and marks LOG_ARCHIVE_DUPLEX_DEST deprecated in favor of numbered destinations in Enterprise Edition^[2]. Deprecation does not mean the parameter has disappeared from every supported configuration.

Inventory a legacy system before migration. Check edition restrictions, active parameters, FRA use, and the required-success policy. Do not combine the legacy destination family with the numbered-destination example. Plan the transition, preserve its original settings, and verify the new configuration before treating migration as complete. The old tutorial's application credentials and GUI simulation are not part of this procedure.

Diagnose failures and preserve the recovery policy

Changing a destination to DEFER or reducing the minimum can weaken the protection requirement. Such a change belongs in a reviewed incident procedure, with its consequences recorded. Prefer repairing the underlying destination when that meets the availability requirement. Repeatedly changing settings without preserving their previous values makes both diagnosis and rollback harder.

Rollback means restoring the exact recorded destination strings, states, and persistence settings. It is not a generic command to blank destination 2. After restoration, inspect the effective policy, test archival as appropriate, and verify the expected copies again. Preserve generated logs until the retention and recovery requirements permit their removal.

Complete the acceptance record

A useful completion record states which database and container were tested, which storage paths were used, and whether one or two successful copies were required. Include the before-and-after settings, destination status, matching sequence evidence, actual file checks, and any unresolved errors. Keep the rollback values with that record so another DBA can understand the change.

Multiple archive destinations protect only one part of the recovery chain. Datafile backups, control-file and SPFILE protection, archived-redo availability, and tested recovery procedures must work together. The next lesson explains how to detect and repair corrupted blocks.

Terminology

[1] Destination identifier: the numeric suffix associated with an archive destination and its DEST_ID. It is not a user connection or transaction handle.

[2] Deprecated: retained for compatibility while a preferred replacement is documented. Check the specific release and edition before deciding whether a feature remains supported.

Oracle documentation

• Destination slots and attribute restrictions
• Required successful archive destinations
• Online redo groups and members
• Archive destination status and archived-log records
• Recovery-area configuration
• Legacy duplex destination parameter