Oracle Enable FAL Tracing on Primary Database

calendar Nov 28, 2025 / · 4 min read · Oracle Database Data Guard Backup and Recovery Database Administration Troubleshooting Archive Logs FAL Redo Transport  ·
Share on: linkedin copy

Oracle Enable FAL Tracing on Primary Database

Purpose

Enabling FAL (Fetch Archive Log) tracing on the primary database helps database administrators monitor and troubleshoot archive log gap resolution between primary and standby databases in Oracle Data Guard environments. This command activates detailed trace logging for the FAL server process, which handles requests from standby databases when they detect missing archive logs. The trace output provides valuable diagnostic information for resolving synchronization issues and understanding redo transport behavior.

Code Breakdown

Original Code

1-- Turn on fal tracing on the primary db
2alter system set LOG_ARCHIVE_TRACE = 128;

Command Structure

ALTER SYSTEM is the Oracle SQL command used to dynamically modify system parameters without restarting the database. The SET clause specifies which initialization parameter to modify.

LOG_ARCHIVE_TRACE is an integer parameter that controls the generation of trace information for log archiving and redo transport activities. This parameter can be set to various numeric values that represent different tracing levels, and these values can be combined by adding them together.

Value 128 specifically enables tracing for the FAL (Fetch Archive Log) engine. The FAL engine on the primary database services requests from standby databases that need to retrieve missing archived redo logs to resolve gaps in their sequence.

Key Points

What is FAL?

FAL stands for Fetch Archive Log, a critical component of Oracle Data Guard architecture. The FAL server runs on the primary database as a foreground process that responds to requests from standby databases. When a standby database detects a gap in its archive log sequence, the MRP (Managed Recovery Process) triggers a FAL client request to retrieve the missing logs.

Trace Level Values

The LOG_ARCHIVE_TRACE parameter accepts multiple values that can be combined to track different aspects of redo transport:

  • 0: Disables all archivelog tracing (default)
  • 1: High-level tracing from most redo transport processes
  • 4: Tracks archivelog history
  • 8: Tracks database protection mode
  • 16: Tracks disk and network I/O requests
  • 32: Tracks redo transport destinations
  • 64: Tracks redo transport archive engine
  • 128: Tracks redo transport FAL engine
  • 256: Tracks RFS process clients

When to Enable FAL Tracing

Enable FAL tracing when experiencing these issues:

  • Standby databases report archive log gaps that are not resolving automatically
  • Manual gap resolution is required frequently
  • Primary database shows no indication of FAL requests in alert logs
  • Investigating performance issues with archive log shipping
  • Troubleshooting connectivity between primary and standby databases

Trace Output Location

When LOG_ARCHIVE_TRACE is set to 128, detailed trace information appears in trace files for multiple processes including the archive process (ARCn), LGWR process, and foreground processes. The trace files help identify duplicate requests, connection failures, and successful archive log transfers.

Insights

Dynamic Configuration

The ALTER SYSTEM command with this parameter takes effect immediately without requiring a database restart. This allows administrators to enable tracing on-demand when troubleshooting issues, then disable it afterward to reduce overhead.

Combining Trace Levels

You can enable multiple tracing levels simultaneously by adding the values together. For example, setting LOG_ARCHIVE_TRACE to 192 (128 + 64) would trace both the FAL engine and the archive engine, providing comprehensive visibility into the entire archive log transfer process.

Automatic Gap Resolution Evolution

Starting with Oracle 9.2.0, automatic gap resolution was enhanced so the ARCH process on the primary database polls all standby databases every minute to detect gaps. However, FAL tracing remains essential for troubleshooting when automatic resolution fails or for understanding the communication patterns between primary and standby databases.

Oracle 11.2 and Later

In Oracle 11.2 and later versions, the FAL_CLIENT parameter is no longer strictly required, as Oracle automatically uses the DB_UNIQUE_NAME or log_archive_dest_n configuration. This simplification means FAL requests can be serviced even without explicit FAL_CLIENT configuration, but tracing helps verify the process is working correctly.

Performance Considerations

While LOG_ARCHIVE_TRACE provides valuable diagnostic information, enabling extensive tracing on production systems can generate significant trace file output. It is recommended to enable FAL tracing only during troubleshooting periods and return it to 0 when the issue is resolved to minimize performance impact.

Disabling FAL Tracing

To disable FAL tracing after troubleshooting is complete, execute:

1alter system set LOG_ARCHIVE_TRACE = 0;

This returns logging to the default state where only error conditions generate alert and trace entries.

References

Posts in this series