How to Disable and Enable Oracle Archive Log Destinations

How to Disable and Enable Oracle Archive Log Destinations

Purpose

Coordinating redo shipping around a standby maintenance window is an operational task every Data Guard DBA runs into: the standby is about to go down for patching, storage work, or a network change, and the primary database needs to keep generating and archiving redo without erroring against a destination that is temporarily unreachable. Dropping the destination configuration outright is the wrong tool for this — it throws away carefully tuned attributes (service name, compression, delay settings) that would need to be rebuilt from scratch once the standby comes back. What the situation actually calls for is a way to pause and resume shipping to one specific destination while the rest of the configuration stays untouched.

LOG_ARCHIVE_DEST_STATE_n is that control. Setting it to defer on a target destination immediately stops Oracle from shipping to that destination, while every other attribute of LOG_ARCHIVE_DEST_n — the destination string, the transport mode, the VALID_FOR clause — stays in memory exactly as configured. Setting it back to enable resumes shipping without requiring any of that configuration to be re-entered. This post covers the two-command pair that does this, the two lesser-used state values Oracle also supports, how to verify the change actually took effect, and the RAC and multitenant details that change how the command needs to be issued.

Breakdown of Code

Original Code

1-- Disable/Enable archive log destinations
2alter system set log_archive_dest_state_2 = 'defer';
3alter system set log_archive_dest_state_2 = 'enable';

Command Explanation

First Command: Defer (Disable)

1alter system set log_archive_dest_state_2 = 'defer';

This command temporarily disables the second archive log destination. When you defer a destination, Oracle preserves all the destination information and settings but excludes it from archiving operations. The redo logs will not be sent to this destination until you enable it again.

Second Command: Enable (Activate)

1alter system set log_archive_dest_state_2 = 'enable';

This command activates the second archive log destination. The destination becomes available for archiving operations immediately, and Oracle resumes sending archived redo logs to this location.

Persisting the change with SCOPE

Both commands as written are memory-only — they apply to the running instance but revert to whatever is in the spfile or init.ora at the next instance restart. Adding scope=both (or scope=spfile if the change should not take effect until the next bounce) writes the new state to the persistent parameter file as well:

1alter system set log_archive_dest_state_2 = 'defer' scope=both;

For a planned, multi-day standby outage this distinction matters. A memory-only defer issued before a maintenance window will silently revert to enable if the primary instance itself is restarted mid-window — for example, by an unrelated patching activity — and the primary will resume attempting to ship redo to a standby that is still down. scope=both avoids that surprise.

Key Points

• Non-destructive operation: Using defer does not delete the destination configuration; it only makes it temporarily unavailable.
• Destination numbering: Oracle supports multiple archive destinations, referenced as LOG_ARCHIVE_DEST_1 through higher-numbered slots, each with its own independent LOG_ARCHIVE_DEST_STATE_n control.
• Default state: The default state for any configured archive destination is enable.
• Immediate effect for memory-scope changes: A plain alter system set without scope= takes effect immediately for the running instance, without requiring a database restart.
• Data Guard usage: Destination 2 is commonly configured for a standby database location in Data Guard setups, though the numbering is a local convention, not a fixed requirement — any destination number can point at a standby.
• Instance-scoped in RAC: On a Real Application Clusters configuration, alter system set without an sid= clause applies to the instance you are connected to. Confirm whether the parameter needs to change on every instance or only the one currently handling archiving duties before assuming a single command covers the whole cluster.

Common Use Cases

Maintenance Operations

You can defer archive destinations when performing maintenance on standby databases to prevent archive log buildup or errors on the primary database. This is useful during:

• Standby database patching or upgrades
• Network maintenance between primary and standby sites
• Storage maintenance on the standby location

Troubleshooting

Deferring destinations helps isolate issues when multiple archive destinations are configured. If one destination experiences problems, you can defer it while investigating without affecting other destinations. This is particularly useful on a configuration with three or more destinations — a cascading standby, a local flash recovery area destination, and a remote disaster-recovery destination all configured together — where deferring the one destination under investigation lets the other two continue operating normally while the alert log and listener logs on the problem destination are reviewed.

Controlled Failover Testing

During disaster recovery testing, administrators can defer and enable destinations to control the flow of redo data and simulate various failure scenarios. Deferring the primary standby destination and confirming the primary database continues normal operation (assuming the destination is not marked MANDATORY) validates that a real standby outage would not itself interrupt production processing.

Additional State Values

Oracle provides four state values for archive destinations:

• enable: Destination is active and receiving archive logs (default).
• defer: Destination is temporarily disabled but configuration is preserved.
• alternate: Destination serves as a backup if primary destinations fail.
• reset: Functions like defer but also clears any previous error messages associated with the destination.

reset is worth calling out separately from defer because the two are easy to confuse. Both stop shipping to the destination. The difference is that reset also clears the destination's recorded error state in V$ARCHIVE_DEST, which matters when a destination has been failing for a known reason (a full standby archive area, a down listener) and you want the next enable attempt to start from a clean error history rather than carrying forward a stale error code from before the fix.

alternate changes how a destination behaves rather than simply turning it on or off — it designates the destination as a standby-of-sorts for another destination, activated automatically only if the primary destination it backs up fails. This is a configuration-time choice tied to the ALTERNATE attribute on LOG_ARCHIVE_DEST_n itself, not something toggled ad hoc the way defer and enable are.

Verification Commands

After changing the destination state, you can verify the configuration using:

1-- Check archive destination status
2SELECT dest_id, status, destination 
3FROM v$archive_dest 
4WHERE dest_id = 2;
5
6-- View archive destination parameters
7SHOW PARAMETER log_archive_dest_state_2;

The V$ARCHIVE_DEST dynamic performance view displays the current state and configuration for all archive destinations. STATUS on this view reflects the destination's actual operational state — VALID, DEFERRED, ERROR, or DISABLED — which is worth checking separately from the parameter value, since a destination can show enable in SHOW PARAMETER while still reporting ERROR in V$ARCHIVE_DEST if the destination itself is unreachable. The two are not the same signal: one shows administrator intent, the other shows what Oracle actually observed on the last attempt.

For a more complete picture on a Data Guard configuration, V$ARCHIVE_DEST_STATUS extends the same information with the archiver process that last wrote to the destination and the SCN last successfully shipped — useful for confirming a re-enabled destination has actually resumed shipping rather than just reporting VALID with no recent activity.

Best Practices

• Always verify the destination state before performing maintenance operations.
• Document the reason when deferring destinations for audit and troubleshooting purposes.
• Monitor alert logs for archive-related errors after re-enabling destinations.
• Use the scope=both parameter to persist changes across database restarts: alter system set log_archive_dest_state_2 = 'defer' scope=both;
• In Data Guard environments, coordinate with the standby database team before changing destination states.
• Check whether the destination is marked MANDATORY before deferring it. A MANDATORY destination that cannot be reached, and has not been explicitly deferred, can stall log switches on the primary once local archive space is exhausted — deferring it deliberately, with the team's knowledge, is safer than leaving an unreachable mandatory destination to fail silently and back up the primary instance.
• After a planned re-enable, confirm the standby has actually caught up rather than assuming the command succeeded. A large gap accumulated during the deferred window can take time to close, and the destination can show enable/VALID well before the standby is current.

Troubleshooting Common Issues

Destination shows enable but no new redo is arriving. Check V$ARCHIVE_DEST.ERROR for the destination — a network path issue, an expired standby redo log, or a listener problem on the standby side can leave the parameter set to enable while shipping still fails. STATUS will typically show ERROR in this case even though the state parameter itself reads enable.

A defer issued during a maintenance window did not survive an unplanned primary restart. This is the memory-scope gap described above. Reissue the command with scope=both for any deferral expected to last through a possible primary bounce, and confirm the destination's state after any unplanned restart before assuming the deferral is still in place.

alter system set log_archive_dest_state_2 returns an error on a destination that does not exist. The destination number in the command must correspond to a LOG_ARCHIVE_DEST_2 that has already been configured with alter system set log_archive_dest_2 = '...'. The state parameter controls an existing destination; it does not create one.

A cluster-wide expectation that one instance's change applies everywhere. On RAC, confirm whether the archiving configuration is common across instances or per-instance before assuming a single alter system set reached every node. Where the setting needs to apply cluster-wide, issue it against each instance or use the appropriate cluster-wide syntax rather than relying on one instance's change to propagate.

References

• LOG_ARCHIVE_DEST_STATE_n - Official Oracle Database reference documentation for LOG_ARCHIVE_DEST_STATE_n, including the enable, defer, alternate, and reset values
• Managing Archived Redo Log Files - Oracle Database Administrator's Guide covering archive destination configuration and management practices
• oracle-base.com - Tim Hall's Oracle reference site, a broad source for further archive log and Data Guard configuration walkthroughs
• asktom.oracle.com - Tom Kyte's historical Q&A archive, useful for cross-referencing archive destination state edge cases